为何编写此文档

Why this document was written

好吧，我发现 HOWTO 中有一大片空白，缺少有关新 Linux 2.4.x 内核中的 iptables 和 Netfilter 功能的信息。除此之外，我将尝试回答一些人可能对状态匹配等新可能性提出的问题。其中大部分内容将通过示例rc.firewall.txt文件进行说明，您可以在/etc/rc.d/脚本中使用该文件。是的，这个文件最初是基于伪装的 HOWTO，供那些认识它的人使用。

Well, I found a big empty space in the HOWTO's out there lacking in information about the iptables and Netfilter functions in the new Linux 2.4.x kernels. Among other things, I'm going to try to answer questions that some might have about the new possibilities like state matching. Most of this will be illustrated with an example rc.firewall.txt file that you can use in your /etc/rc.d/ scripts. Yes, this file was originally based upon the masquerading HOWTO for those of you who recognize it.

另外，我编写了一个小脚本，以防万一您在配置过程中像我一样搞砸了，如rc.flush-iptables.txt。

Also, there's a small script that I wrote just in case you screw up as much as I did during the configuration available as rc.flush-iptables.txt.

是怎么写的

How it was written

我最初为 boingworld.com 编写了一个非常小的教程，该网站是一个 Amiga/Linux/General 新闻网站，几年前由一小群人（包括我）运营。由于有大量的读者和评论，我继续写下去。最初的印刷版大约有 10-15 页 A4 页，此后一直在缓慢而稳定地增长。很多人帮助了我，进行拼写检查、错误更正等。在撰写本文时，仅 https://www.frozentux.net/iptables-tutorial/ 网站就有超过 600.000 次独特点击。

I originally wrote this as a very small tutorial for boingworld.com, which was an Amiga/Linux/General newssite that a small group of people, including me, ran a couple of years back. Due to the fantastic amount of readers and comments that I got from it, I continued to write on it. The original version was approximately 10-15 A4 pages in printed version and has since been growing slowly but steadily. A huge amount of people has helped me out, spellchecking, bug corrections, etc. At the time of writing this, the https://www.frozentux.net/iptables-tutorial/ site has had over 600.000 unique hits alone.

本文档旨在指导您逐步完成设置过程，并希望能帮助您了解有关 iptables 包的更多信息。我这里的大部分内容都基于示例 rc.firewall 文件，因为我发现该示例是学习如何使用 iptables 的好方法。我决定只遵循基本的链结构，并从那里遍历遍历的每一条链并解释脚本的工作原理。这样，教程就有点难以理解，尽管这种方式更符合逻辑。每当您发现难以理解的内容时，请返回本教程。

This document was written to guide you through the setup process step by step and hopefully help you to understand some more about the iptables package. I have based most of the stuff here on the example rc.firewall file, since I found that example to be a good way to learn how to use iptables. I decided to just follow the basic chain structure and from there walk through each and one of the chains traversed and explain how the script works. That way the tutorial is a little bit harder to follow, though this way is more logical. Whenever you find something that's hard to understand, just come back to this tutorial.

本文档中使用的术语

Terms used in this document

本文档包含一些术语，在阅读它们之前可能需要更详细的解释。本节将尝试涵盖最明显的内容以及我如何选择在本文档中使用它们。

This document contains a few terms that may need more detailed explanations before you read them. This section will try to cover the most obvious ones and how I have chosen to use them within this document.

连接 - 在本文档中通常将其称为一系列彼此相关的数据包。这些数据包将彼此称为已建立的连接类型。换句话说，连接是一系列交换的数据包。在TCP中，这主要是指通过3次握手建立连接，然后直到释放握手才认为这是一个连接。

Connection - This is generally referred to in this document as a series of packets relating to each other. These packets refer to each other as an established kind of connection. A connection is in another word a series of exchanged packets. In TCP, this mainly means establishing a connection via the 3-way handshake, and then this is considered a connection until the release handshake.

DNAT - 目标网络地址转换。DNAT 是指转换数据包的目标 IP 地址的技术，或者简单地说是更改它的技术。它与 SNAT 一起使用，允许多个主机共享单个 Internet 可路由 IP 地址，并仍然提供服务器服务。这通常是通过为不同的端口分配互联网可路由的 IP 地址来完成的，然后告诉 Linux 路由器将流量发送到哪里。

DNAT - Destination Network Address Translation. DNAT refers to the technique of translating the Destination IP address of a packet, or to change it simply put. This is used together with SNAT to allow several hosts to share a single Internet routable IP address, and to still provide Server Services. This is normally done by assigning different ports with an Internet routable IP address, and then tell the Linux router where to send the traffic.

IPSEC - 互联网协议安全是一种用于加密 IPv4 数据包并通过互联网安全发送它们的协议。有关 IPSEC 的更多信息，请查看其他资源和链接附录，了解有关该主题的其他资源。

IPSEC - Internet Protocol Security is a protocol used to encrypt IPv4 packets and sending them securely over the Internet. For more information on IPSEC, look in the Other resources and links appendix for other resources on the topic.

内核空间——这或多或少与用户空间相反。这意味着操作发生在内核内部，而不是内核外部。

Kernel space - This is more or less the opposite of User space. This implies the actions that take place within the kernel, and not outside of the kernel.

数据包 - 通过网络发送的单个单元，包含标头和数据部分。例如，IP数据包或TCP数据包。在征求意见 (RFC) 中，数据包没有那么概括，IP 数据包称为数据报，而 TCP 数据包称为段。为了简单起见，我选择将本文档中的几乎所有内容称为数据包。

Packet - A singular unit sent over a network, containing a header and a data portion. For example, an IP packet or an TCP packet. In Request For Comments (RFC's) a packet isn't so generalized, instead IP packets are called datagrams, while TCP packets are called segments. I have chosen to call pretty much everything packets in this document for simplicity.

QoS - 服务质量是一种指定数据包应如何处理以及发送数据包时应接收哪种服务质量的方法。有关此主题的更多信息，请查看TCP/IP 复习章节以及有关该主题的外部资源的 其他资源和链接附录。

QoS - Quality of Service is a way of specifying how a packet should be handled and what kind of service quality it should receive while sending it. For more information on this topic, take a look in the TCP/IP repetition chapter as well as the Other resources and links appendix for external resources on the subject.

段 - TCP 段与数据包几乎相同，但它是 TCP 数据包的正式术语。

Segment - A TCP segment is pretty much the same as an packet, but a formalized word for a TCP packet.

流 - 该术语指的是发送和接收以某种方式相互关联的数据包的连接。基本上，我将这个术语用于任何类型的双向发送两个或多个数据包的连接。在 TCP 中，这可能意味着发送 SYN 然后回复 SYN/ACK 的连接，但也可能意味着发送 SYN 然后回复 ICMP 主机不可达的连接。换句话说，我对这个术语的使用非常宽松。

Stream - This term refers to a connection that sends and receives packets that are related to each other in some fashion. Basically, I have used this term for any kind of connection that sends two or more packets in both directions. In TCP this may mean a connection that sends a SYN and then replies with an SYN/ACK, but it may also mean a connection that sends a SYN and then replies with an ICMP Host unreachable. In other words, I use this term very loosely.

SNAT - 源网络地址转换。这是指用于将数据包中的一个源地址转换为另一个源地址的技术。由于目前 IPv4 中可用的 IP 地址短缺（IPv6 将解决这个问题），这使得多个主机可以共享单个 Internet 可路由 IP 地址。

SNAT - Source Network Address Translation. This refers to the techniques used to translate one source address to another in a packet. This is used to make it possible for several hosts to share a single Internet routable IP address, since there is currently a shortage of available IP addresses in IPv4 (IPv6 will solve this).

状态 - 该术语是指数据包所处的状态，根据RFC 793 - 传输控制协议或根据 Netfilter/iptables 中使用的用户端状态。请注意，内部和外部使用的状态并不完全遵循 RFC 793 规范。主要原因是 Netfilter 必须对连接和数据包做出一些假设。

State - This term refers to which state the packet is in, either according to RFC 793 - Transmission Control Protocol or according to userside states used in Netfilter/iptables. Note that the used states internally, and externally, do not follow the RFC 793 specification fully. The main reason is that Netfilter has to make several assumptions about the connections and packets.

用户空间——这个术语指的是内核之外发生的一切。例如，调用 iptables -h 发生在内核外部，而 iptables -A FORWARD -p tcp -j ACCEPT （部分）发生在内核内部，因为新规则已添加到规则集中。

User space - With this term I mean everything and anything that takes place outside the kernel. For example, invoking iptables -h takes place outside the kernel, while iptables -A FORWARD -p tcp -j ACCEPT takes place (partially) within the kernel, since a new rule is added to the ruleset.

用户空间 - 请参阅用户空间。

Userland - See User space.

VPN - 虚拟专用网络是一种用于在非专用网络（例如互联网）上创建虚拟专用网络的技术。IPSEC 是一种用于创建 VPN 连接的技术。OpenVPN 是另一个。

VPN - Virtual Private Network is a technique used to create virtually private networks over non-private networks, such as the Internet. IPSEC is one technique used to create VPN connections. OpenVPN is another.

下一步是什么？

What's next?

本章对为什么编写此文档以及如何编写此文档进行了一些深入的了解。它还解释了整个文档中使用的一些常用术语。

This chapter has given some small insight into why this document was written and how it was written. It also explained some common terms used throughout the document.

下一章将对 TCP/IP 进行相当长的介绍和重复。基本上，这意味着 IP 协议及其一些常与 iptables 和 netfilter 一起使用的子协议。它们是 TCP、UDP、ICMP 和 SCTP。与其他协议相比，SCTP 是一个相当新的标准，因此我们花费了大量的空间和时间来为所有仍然不太熟悉该协议的人描述该协议。下一章还将讨论目前使用的一些基本和更高级的路由技术。

The next chapter will bring up a rather lengthy introduction and repetition to TCP/IP. Basically this means the IP protocol and some of its sub-protocols that are commonly used with iptables and netfilter. These are TCP, UDP, ICMP and SCTP. SCTP is a rather new standard in comparison to the other protocols, hence quite a lot of space and time has gone into describing this protocol for all of those who are still not quite familiar with it. The next chapter will also discuss some basic and more advanced routing techniques used today.

TCP/IP 层

TCP/IP Layers

如前所述，TCP/IP 是多层的。这意味着我们有一个功能在一个深度运行，另一个功能在另一个级别运行，等等。我们拥有所有这些层的原因实际上非常简单。

TCP/IP is, as already stated, multi-layered. This means that we have one functionality running at one depth, and another one at another level, etcetera. The reason that we have all of these layers is actually very simple.

最大的原因是整个架构的可扩展性非常好。例如，我们可以向应用程序层添加新功能，而无需重新实现整个 TCP/IP 堆栈代码，或将完整的 TCP/IP 堆栈包含到实际应用程序中。就像我们每次制作新的网络接口卡时不需要重写每个程序一样。每一层都需要尽可能少地了解彼此，以保持它们的分离。

The biggest reason is that the whole architecture is very extensible. We can add new functionality to the application layers, for example, without having to reimplement the whole TCP/IP stack code, or to include a complete TCP/IP stack into the actual application. Just the same way as we don't need to rewrite every single program, every time that we make a new network interface card. Each layer should need to know as little as possible about each other, to keep them separated.

当我们谈论驻留在内核内部的 TCP/IP 编程代码时，我们通常谈论的是 TCP/IP 堆栈。TCP/IP 堆栈仅意味着使用的所有子层，从网络访问层一直到应用层。 When we are talking about the programming code of TCP/IP which resides inside the kernel, we are often talking about the TCP/IP stack. The TCP/IP stack simply means all of the sublayers used, from the Network access layer and all the way up to the Application layer.

在讨论层时，需要遵循两种基本架构。其中之一是 OSI（开放系统互连）参考模型，由 7 层组成。由于我们对 TCP/IP 层更感兴趣，因此我们在这里仅进行粗浅的了解。然而，从历史的角度来看，了解这一点很有趣，特别是如果您正在使用许多不同类型的网络。OSI 参考模型列表中的各层如下。

There are two basic architectures to follow when talking about layers. One of them is the OSI (Open Systems Interconnect) Reference Model and consists of 7 layers. We will only look at it superficially here since we are more interested in the TCP/IP layers. However, from an historical point, this is interesting to know about, especially if you are working with lots of different types of networks. The layers are as follows in the OSI Reference Model list.

关于这些参考模型中哪一个最常用存在一些讨论，但 OSI 参考模型似乎仍然是流行的参考模型。这也可能取决于您居住的地方，但是，在大多数美国和欧盟国家/地区，您在与技术人员和销售人员交谈时似乎可以默认使用 OSI 参考模型。 There is some discussion as to which of these reference models is mostly used, but it seems that the OSI reference model still is the prevalent reference model. This might also depend on where you live, however, in most US and EU countries it seems as you can default to OSI reference model while speaking to technicians and salespeople. 然而，在本文档的其余部分中，除非另有说明，我们将主要参考 TCP/IP 参考模型。 However, throughout the rest of this document, we will mainly refer to the TCP/IP reference model, unless otherwise noted.

1. 应用层

2. Application layer

3. 表示层

4. Presentation layer

5. 会话层

6. Session layer

7. 传输层

8. Transport layer

9. 网络层

10. Network layer

11. 数据链路层

12. Data Link layer

13. 物理层

14. Physical layer

我们发送的数据包从该列表的顶部到底部，每一层都在我们所说的封装阶段向数据包添加自己的一组标头。当数据包最终到达目的地时，数据包将向后遍历列表，并且标头被一个接一个地从数据包中剥离，每个标头为目标主机提供数据包数据最终到达应用程序或程序所需的所有信息这是注定的。

A packet that is sent by us, goes from the top and to the bottom of this list, each layer adding its own set of headers to the packet in what we call the encapsulation phase. When the packet finally reaches it's destination the packet goes backwards through the list and the headers are stripped out of the packet, one by one, each header giving the destination host all of the needed information for the packet data to finally reach the application or program that it was destined for.

我们更感兴趣的第二个也是更有趣的分层标准是 TCP/IP 协议体系结构，如TCP/IP 体系结构列表所示。对于 TCP/IP 体系结构有多少层，人们并没有达成普遍共识。然而，通常认为有3到5层可用，并且在大多数图片和解释中，将讨论4层。为了简单起见，我们将只考虑通常讨论的那四个层。

The second and more interesting layering standard that we are more interested in is the TCP/IP protocol architecture, as shown in the TCP/IP architecture list. There is no universal agreement among people on just how many layers there are in the TCP/IP architecture. However, it is generally considered that there are 3 through 5 layers available, and in most pictures and explanations, there will be 4 layers discussed. We will, for simplicities sake, only consider those four layers that are generally discussed.

1. 应用层

2. Application layer

3. 传输层

4. Transport layer

5. 互联网层

6. Internet layer

7. 网络接入层

8. Network Access layer

正如您所看到的，TCP/IP 协议集的体系结构非常类似于 OSI 参考模型，但又并非如此。与 OSI 参考模型一样，我们为进入或离开的每一层添加和减去标头。

As you can see, the architecture of the TCP/IP protocol set is very much like the OSI Reference Model, but yet not. Just the same as with the OSI Reference Model, we add and subtract headers for each layer that we enter or leave.

例如，让我们使用现代计算机网络最常见的类比之一——蜗牛邮件。一切都是按步骤完成的，就像 TCP/IP 中的一切一样。

For example, lets use one of the most common analogies to modern computer networking, the snail-mail letter. Everything is done in steps, just as is everything in TCP/IP.

您想给某人写一封信，询问他们的近况以及他们在做什么。为此，您必须首先创建数据或问题。实际数据将位于应用程序层内部。

You want to send a letter to someone asking how they are, and what they are doing. To do this, you must first create the data, or questions. The actual data would be located inside the Application layer.

之后，我们将写在一张纸上的数据放入信封内，并在上面写上这封信的收件人是特定公司或家庭中的谁。也许像下面的例子：

After this we would put the data written on a sheet of paper inside an envelope and write on it to whom the letter is destined for within a specific company or household. Perhaps something like the example below:

这相当于 TCP/IP 中的传输层。在传输层中，如果我们处理 TCP，则这相当于某个端口（例如端口 25）。

This is equivalent to the the Transport layer, as it is known in TCP/IP. In the Transport layer, if we were dealing with TCP, this would have been equivalent to some port (e.g., port 25).

此时我们将收件人的地址写在信封上，比如这样：

At this point we write the address on the envelope of the recipient, such as this:

类比起来，这与互联网层相同。互联网层包含告诉我们在 TCP/IP 网络中到达接收者或主机的位置的信息。就像信封上的收件人一样。换句话说，这相当于 IP 地址（例如，IP 192.168.0.4）。

This would in the analogy be the same as the Internet layer. The internet layer contains information telling us where to reach the recipient, or host, in a TCP/IP network. Just the same way as the recipient on an envelope. This would be the equivalent of the IP address in other words (e.g., IP 192.168.0.4).

最后一步是将整封信放入邮箱。这样做大约相当于将数据包放入网络访问层。网络访问层包含用于访问数据包传输的实际物理网络的功能和例程。

The final step is to put the whole letter in a postbox. Doing this would approximately equal to putting a packet into the Network Access Layer. The network access layer contains the functions and routines for accessing the actual physical network that the packet should be transported over.

当收件人最终收到信件时，他会从信封和地址等中打开整封信（拆封）。他收到的信可能需要回复，也可能不需要。在任何一种情况下，接收者都可以通过颠倒他收到的原始信件上的接收者和发送者地址来回复该信件，以便接收者成为发送者，发送者成为接收者。

When the receiver finally receives the letter, he will open the whole letter from the envelope and address etc (decapsulate it). The letter he receives may either require a reply or not. In either case, the letter may be replied upon by the receiver, by reversing the receiver and transmitter addresses on the original letter he received, so that receiver becomes transmitter, and transmitter becomes receiver.

理解 iptables 过去和现在都是专门为在互联网和传输层的标头上工作而构建的这一点非常重要。也可以在应用程序和网络访问层中使用 iptables 进行一些非常基本的过滤，但它不是为此设计的，也不是非常适合这些目的。 It is very important to understand that iptables was and is specifically built to work on the headers of the Internet and the Transport layers. It is possible to do some very basic filtering with iptables in the Application and Network access layers as well, but it was not designed for this, nor is it very suitable for those purposes. 例如，如果我们使用字符串匹配并匹配数据包内的特定字符串，例如 get /index.html。那行得通吗？通常情况下，是的。但是，如果数据包大小非常小，则不会。原因是 iptables 是基于每个数据包工作 的，这意味着如果字符串被分成几个单独的数据包，iptables 将看不到整个字符串。因此，在应用程序层中使用某种代理进行过滤会更好。我们将在稍后的IP 过滤介绍中更详细地讨论这些问题。 For example, if we use a string match and match for a specific string inside the packet, lets say get /index.html. Will that work? Normally, yes. However, if the packet size is very small, it will not. The reason is that iptables is built to work on a per packet basis, which means that if the string is split into several separate packets, iptables will not see that whole string. For this reason, you are much, much better off using a proxy of some sort for filtering in the application layer. We will discuss these problems in more detail later on in the IP filtering introduction.

由于 iptables 和 netfilter 主要在互联网层和传输层中运行，因此我们将在本章接下来的部分中重点关注这些层。在互联网层下，我们几乎只会看到IP协议。对此还有一些补充，例如 GRE 协议，但它们在互联网上非常罕见。此外，iptables（顾名思义）也没有很好地关注这些协议。由于所有这些因素，我们将主要关注互联网层的 IP 协议以及传输层的 TCP、UDP 和 ICMP。

As iptables and netfilter mainly operate in the Internet and Transport layers, that is the layers that we will put our main focus in, in the upcoming sections of this chapter. Under the Internet layer, we will almost exclusively see the IP protocol. There are a few additions to this, such as, for example, the GRE protocol, but they are very rare on the internet. Also, iptables is (as the name implies) not focused around these protocols very well either. Because of all these factors we will mainly focus around the IP protocol of the Internet layer, and TCP, UDP and ICMP of the Transport layer.

ICMP 协议实际上是两层之间的混合。它运行在互联网层，但它具有与 IP 协议完全相同的标头，但也有一些额外的标头，然后直接在该封装内存放数据。我们将在ICMP 特性中进一步详细讨论这一点。 The ICMP protocol is actually sort of a mix between the two layers. It runs in the Internet layer, but it has the exact same headers as the IP protocol, but also a few extra headers, and then directly inside that encapsulation, the data. We will discuss this in more detail further on, in the ICMP characteristics.

IP 特点

IP characteristics

正如我们已经说过的，IP 协议驻留在互联网层。IP 协议是 TCP/IP 堆栈中的协议，负责让您的机器、路由器、交换机等了解特定数据包的去向。该协议是整个 TCP/IP 堆栈的核心，并且构成了 Internet 中一切事物的基础。

The IP protocol resides in the Internet layer, as we have already said. The IP protocol is the protocol in the TCP/IP stack that is responsible for letting your machine, routers, switches and etcetera, know where a specific packet is going. This protocol is the very heart of the whole TCP/IP stack, and makes up the very foundation of everything in the Internet.

IP 协议封装传输层数据包，其中包含有关其来自哪个传输层协议、要去哪台主机、来自何处以及一些其他有用信息的信息。当然，所有这一切都是极其精确的标准化，具体到每一个比特。这同样适用于我们将在本章中讨论的每个协议。

The IP protocol encapsulates the Transport layer packet with information about which Transport layer protocol it came from, what host it is going to, and where it came from, and a little bit of other useful information. All of this is, of course, extremely precisely standardized, down to every single bit. The same applies to every single protocol that we will discuss in this chapter.

IP 协议有一些它必须能够处理的基本功能。它必须能够定义数据报，这是传输层创建的下一个构建块（换句话说，例如可以是 TCP、UDP 或 ICMP）。IP 协议还定义了我们今天使用的互联网寻址系统。这意味着 IP 协议定义了主机之间如何到达，当然，这也影响了我们如何路由数据包。我们所说的地址就是我们通常所说的IP地址。通常，当我们谈论 IP 地址时，我们谈论的是点分四组数字（例如127.0.0.1）。这主要是为了使 IP 地址更易于人眼读取，因为 IP 地址实际上只是一个由 1 和 0 组成的 32 位字段（127.0.0.1因此在实际的 IP 标头中将被读取为 01111111000000000000000000000001）。

The IP protocol has a couple of basic functionalities that it must be able to handle. It must be able to define the datagram, which is the next building block created by the transport layer (this may in other words be TCP, UDP or ICMP for example). The IP protocol also defines the Internet addressing system that we use today. This means that the IP protocol is what defines how to reach between hosts, and this also affects how we are able to route packets, of course. The addresses we are talking about are what we generally call an IP address. Usually when we talk about IP addresses, we talk about dotted quad numbers (e.g., 127.0.0.1). This is mostly to make the IP addresses more readable for the human eye, since the IP address is actually just a 32 bit field of 1's and 0's (127.0.0.1 would hence be read as 01111111000000000000000000000001 within the actual IP header).

IP 协议还有更多的魔力，它必须发挥它的作用。它还必须能够解封装和封装 IP 数据报（IP 数据），并从网络访问层或传输层发送或接收数据报。这似乎是显而易见的，但有时并非如此。最重要的是，它还必须执行两项重要功能，这将是防火墙和路由社区非常感兴趣的。IP 协议负责将数据包从一台主机路由到另一台主机，以及我们可能从一台主机接收到的发往另一台主机的数据包。大多数情况下，在单个网络访问主机上，这是一个非常简单的过程。您有两种不同的选择，要么数据包发往我们本地连接的网络，要么可能通过默认网关。但是，一旦开始使用防火墙或安全策略以及多个网络接口和不同的路由，这可能会给许多网络管理员带来相当大的麻烦。IP 协议的最后一个职责是，它必须对先前已分段的任何数据报进行分段并重新组装，或者需要分段以适应我们所连接的特定网络硬件拓扑的数据包大小。如果这些数据包碎片足够小，它们也可能给防火墙管理员带来非常烦人的头痛。问题是，一旦它们被分割成足够小的块，我们甚至在读取数据包的标头时都会遇到问题，更不用说实际的数据了。这可能会让很多网络管理员感到相当头疼。IP 协议的最后一个职责是，它必须对先前已分段的任何数据报进行分段并重新组装，或者需要分段以适应我们所连接的特定网络硬件拓扑的数据包大小。如果这些数据包碎片足够小，它们也可能给防火墙管理员带来非常烦人的头痛。问题是，一旦它们被分割成足够小的块，我们甚至在读取数据包的标头时都会遇到问题，更不用说实际的数据了。这可能会让很多网络管理员感到相当头疼。IP 协议的最后一个职责是，它必须对先前已分段的任何数据报进行分段并重新组装，或者需要分段以适应我们所连接的特定网络硬件拓扑的数据包大小。如果这些数据包碎片足够小，它们也可能给防火墙管理员带来非常烦人的头痛。问题是，一旦它们被分割成足够小的块，我们甚至在读取数据包的标头时都会遇到问题，更不用说实际的数据了。或者需要进行分段以适应我们所连接的特定网络硬件拓扑的数据包大小。如果这些数据包碎片足够小，它们也可能给防火墙管理员带来非常烦人的头痛。问题是，一旦它们被分割成足够小的块，我们甚至在读取数据包的标头时都会遇到问题，更不用说实际的数据了。或者需要进行分段以适应我们所连接的特定网络硬件拓扑的数据包大小。如果这些数据包碎片足够小，它们也可能给防火墙管理员带来非常烦人的头痛。问题是，一旦它们被分割成足够小的块，我们甚至在读取数据包的标头时都会遇到问题，更不用说实际的数据了。

The IP protocol has even more magic it must perform up it's sleeve. It must also be able to decapsulate and encapsulate the IP datagram (IP data) and send or receive the datagram from either the Network access layer, or the transport layer. This may seem obvious, but sometimes it is not. On top of all this, it has two big functions it must perform as well, that will be of quite interest for the firewalling and routing community. The IP protocol is responsible for routing packets from one host to another, as well as packets that we may receive from one host destined for another. Most of the time on single network access host, this is a very simple process. You have two different options, either the packet is destined for our locally attached network, or possibly through a default gateway. but once you start working with firewalls or security policies together with multiple network interfaces and different routes, it may cause quite some headache for many network administrators. The last of the responsibilities for the IP protocol is that it must fragment and reassemble any datagram that has previously been fragmented, or that needs to be fragmented to fit in to the packetsize of this specific network hardware topology that we are connected to. If these packet fragments are sufficiently small, they may cause a horribly annoying headache for firewall administrators as well. The problem is, that once they are fragmented to small enough chunks, we will start having problems to read even the headers of the packet, not to mention the actual data.

从 Linux 内核 2.4 系列和 iptables 开始，这对于大多数 Linux 防火墙来说应该不再是问题。iptables 用于状态匹配和 NAT 等的连接跟踪系统必须能够读取经过碎片整理的数据包。因此，conntrack 在所有数据包到达内核中的 netfilter/iptables 结构之前自动对所有数据包进行碎片整理。 As of Linux kernel 2.4 series, and iptables, this should no longer be a problem for most linux firewalls. The connection tracking system used by iptables for state matching and NAT'ing etc must be able to read the packet defragmented. Because of this, conntrack automatically defragments all packets before they reach the netfilter/iptables structure in the kernel.

IP协议也是无连接协议，这又意味着IP不“协商”连接。另一方面，面向连接的协议协商连接（称为握手）），然后当所有数据发送完毕后，将其撕毁。TCP 是此类协议的一个示例，但它是在 IP 协议之上实现的。还没有面向连接的原因有几个，但其中之一是，此时还不需要握手，因为还有其他协议，这会增加不必要的高开销，并且是以这种方式弥补的如果我们没有得到答复，我们就知道数据包在传输过程中的某个地方丢失了，并重新发送原始请求。正如您所看到的，在这种情况下，发送请求然后等待指定的时间进行回复，比先发送一个数据包表示我们要打开连接，然后接收一个数据包让我们知道要好得多被打开，然后 实际发送请求，然后发送另一个数据包以断开连接并等待另一个答复。

The IP protocol is also a connectionless protocol, which in turn means that IP does not "negotiate" a connection. a connection-oriented protocol on the other hand negotiates a connection (called a handshake) and then when all data has been sent, tears it down. TCP is an example of this kind of protocol, however, it is implemented on top of the IP protocol. The reason for not being connection-oriented just yet are several, but among others, a handshake is not required at this time yet since there are other protocols that this would add an unnecessarily high overhead to, and that is made up in such a way that if we don't get a reply, we know the packet was lost somewhere in transit anyways, and resend the original request. As you can see, sending the request and then waiting for a specified amount of time for the reply in this case, is much preferred over first sending one packet to say that we want to open a connection, then receive a packet letting us know it was opened, and finally acknowledge that we know that the whole connection is actually open, and then actually send the request, and after that send another packet to tear the connection down and wait for another reply.

IP也被称为 不可靠协议，或者简单地说它不知道是否收到数据包。它只是从传输层接收数据包并执行其操作，然后将其传递到网络访问层，然后仅此而已。它可能会收到一个返回数据包，该数据包从网络访问层遍历到 IP 协议，IP 协议再次执行该操作，然后将其向上传递到传输层。但是，它并不关心是否收到回复数据包，或者另一端是否收到该数据包。同样的情况也适用于 IP 的不可靠性和无连接性，因为不可靠性需要向发送的每个数据包添加额外的回复数据包。例如，让我们考虑 DNS 查找。事实上，我们发送了一个针对 servername.com 的 DNS 请求。如果我们从未收到回复，我们就知道出了问题并重新请求查找，但在正常使用期间，我们会发出一个请求，并得到一个回复​​。增加该协议的可靠性意味着请求将需要两个数据包（一个请求，一个确认已收到数据包），然后需要两个数据包用于回复（一个回复，一个用于确认已收到回复的回复）。换句话说，我们只是将需要发送的数据包数量增加了一倍，并且将需要传输的数据量几乎增加了一倍。

IP is also known as an unreliable protocol, or simply put it does not know if a packet was received or not. It simply receives a packet from the transport layer and does its thing, and then passes it on to the network access layer, and then nothing more to it. It may receive a return packet, which traverses from network access layer to the IP protocol which does it's thing again, and then passes it on upwards to the Transport layer. However, it doesn't care if it gets a reply packet, or if the packet was received at the other end. Same thing applies for the unreliability of IP as for the connectionless-ness, since unreliability would require adding an extra reply packet to each packet that is sent. For example, let us consider a DNS lookup. As it is, we send a DNS request for servername.com. If we never receive a reply, we know something went wrong and re-request the lookup, but during normal use we would send out one request, and get one reply back. Adding reliability to this protocol would mean that the request would require two packets (one request, and one confirmation that the packet was received) and then two packets for the reply (one reply, and one reply to acknowledge the reply was received). In other words, we just doubled the amount of packets needed to send, and almost doubled the amount of data needed to be transmitted.

IP 标头

IP headers

正如您从前面的 IP 协议介绍中所了解的那样，IP 数据包的标头中包含几个不同的部分。整个标头被精心划分为不同的部分，标头的每个部分都被分配尽可能小的一块来完成它的工作，只是为了给协议尽可能少的开销。您将在IP 标头图像中看到 IP 标头的确切配置。

The IP packet contains several different parts in the header as you have understood from the previous introduction to the IP protocol. The whole header is meticuluously divided into different parts, and each part of the header is allocated as small of a piece as possible to do it's work, just to give the protocol as little overhead as possible. You will see the exact configuration of the IP headers in the IP headers image.

请注意，不同标头的解释非常简短，我们只会讨论它们的绝对基础知识。对于我们讨论的每种类型的标头，我们还将列出正确的 RFC，您应该阅读这些 RFC，以进一步了解相关协议并进行技术解释。作为本说明的旁注，RFC 代表请求评论，但如今，它们对互联网社区具有完全不同的含义。与研究人员开始互相编写 RFC 时相比，它们定义并标准化了整个互联网。当时，它们只是征求意见和询问其他研究人员意见的一种方式。 Understand that the explanations of the different headers are very brief and that we will only discuss the absolute basics of them. For each type of header that we discuss, we will also list the proper RFC's that you should read for further understanding and technical explanations of the protocol in question. As a sidenote to this note, RFC stands for Request For Comments, but these days, they have a totally different meaning to the Internet community. They are what defines and standardises the whole Internet, compared to what they were when the researchers started writing RFC's to each other. Back then, they were simply requests for comments and a way of asking other researchers about their opinions.

IP协议主要在RFC 791-Internet Protocol中描述。然而，此 RFC 也由RFC 1349 - Internet 协议套件中的服务类型更新，该 RFC 已被RFC 2474 - IPv4 和 IPv6 标头中区分服务字段（DS 字段）的定义废弃，并由RFC更新 3168 - 在 IP和RFC 3260中添加显式拥塞通知 (ECN) - Diffserv 的新术语和说明。

The IP protocol is mainly described in RFC 791 - Internet Protocol. However, this RFC is also updated by RFC 1349 - Type of Service in the Internet Protocol Suite, which was obsoleted by RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, and which was updated by RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP and RFC 3260 - New Terminology and Clarifications for Diffserv.

正如您所看到的，所有这些标准有时都有点难以遵循。查找彼此相关的不同 RFC 的一个技巧是使用RFC-editor.org上提供的搜索功能。就 IP 而言，请考虑 RFC 791 是基本 RFC，所有其他内容都只是对该标准的更新和更改。当我们讨论这些较新的 RFC 更改的特定标头时，我们将更详细地讨论这些内容。 As you can see, all of these standards can get a little bit hard to follow at times. One tip for finding the different RFC's that are related to each other is to use the search functions available at RFC-editor.org. In the case of IP, consider that the RFC 791 is the basic RFC, and all of the other are simply updates and changes to that standard. We will discuss these more in detail when we get to the specific headers that are changed by these newer RFC's. 要记住的一件事是，有时 RFC 可能会被废弃（根本不使用）。通常这意味着 RFC 已经进行了如此彻底的更新，最好简单地替换整个内容。它也可能由于其他原因而变得过时。当 RFC 过时时，会向原始 RFC 添加一个指向新 RFC 的字段。 One thing to remember is, that sometimes, an RFC can be obsoleted (not used at all). Normally this means that the RFC has been so drastically updated and that it is better to simply replace the whole thing. It may also become obsolete for other reasons as well. When an RFC becomes obsoleted, a field is added to the original RFC that points to the new RFC instead.

版本 - 位 0-3。这是二进制 IP 协议的版本号。IPv4称为0100，而IPv6称为0110。该字段一般不太用于过滤。RFC 791 中描述的版本是 IPv4。

Version - bits 0-3. This is a version number of the IP protocol in binary. IPv4 iscalled 0100, while IPv6 is called 0110. This field is generally not used for filtering very much. The version described in RFC 791 is IPv4.

IHL（互联网标头长度）- 位 4-7。该字段告诉我们 IP 标头在 32 位字中的长度。正如您所看到的，我们也在图像中以这种方式分割标题（每行 32 位）。由于选项字段的长度是可选的，因此如果没有该字段，我们永远无法绝对确定整个标头的长度。标头的最小长度为 5 个字。

IHL (Internet Header Length) - bits 4-7. This field tells us how long the IP header is in 32 bit words. As you can see, we have split the header up in this way (32 bits per line) in the image as well. Since the Options field is of optional length, we can never be absolutely sure of how long the whole header is, without this field. The minimum length of this of the header is 5 words.

服务类型、DSCP、ECN - 位 8-15。这是 IP 标头中最复杂的区域之一，原因很简单，它已经更新了 3 次。它的基本用法始终相同，但实现已经改变了几次。首先，该字段称为服务类型字段。该字段的位[0-2]称为优先字段。位[3]是正常/低延迟，位[4]是正常/高吞吐量，位[5]是正常/高可靠性，位[6-7]被保留以供将来使用。这仍然在很多硬件较旧的地方使用，并且仍然给互联网带来一些问题。其中，位 [6-7] 被指定设置为 0。在 ECN 更新（RFC 3168）中，我们开始使用这些保留位，因此将这些位设置为 0 以外的其他值。但许多旧的防火墙和路由器都内置了检查功能，检查这些位是否设置为 1，如果数据包设置为 1，则数据包将被丢弃。如今，这显然违反了 RFC，但除了抱怨之外，您对此无能为力。

Type of Service, DSCP, ECN - bits 8-15. This is one of the most complex areas of the IP header for the simple reason that it has been updated 3 times. It has always had the same basic usage, but the implementation has changed several times. First the field was called the Type of Service field. Bit [0-2] of the field was called the Precedence field. Bit [3] was Normal/Low delay, Bit [4] was Normal/High throughput, Bit [5] was Normal/High reliability and bit [6-7] was reserved for future usage. This is still used in a lot of places with older hardware, and it still causes some problems for the Internet. Among other things, bit [6-7] are specified to be set to 0. In the ECN updates (RFC 3168, we start using these reserved bits and hence set other values than 0 to these bits. But a lot of old firewalls and routers have built in checks looking if these bits are set to 1, and if the packets do, the packet is discarded. Today, this is clearly a violation of RFC's, but there is not much you can do about it, except to complain.

该字段的第二次迭代是该字段更改为 RFC 2474 中定义的 DS 字段。DS 代表差异化服务。根据此标准，位 [0-5] 是差分服务代码点 (DSCP)，其余两位 [6-7] 仍然未使用。DSCP 字段的使用方式与之前使用 ToS 字段的方式几乎相同，用于标记如果所讨论的路由器在它们之间有任何区别，则应将该数据包视为哪种服务。一个重大变化是设备必须忽略未使用的位才能完全符合 RFC 2474，这意味着只要设备创建者遵循此 RFC，我们就可以摆脱之前解释的麻烦。

The second iteration of this field was when the field was changed into the DS field as defined in RFC 2474. DS stands for Differentiated Services. According to this standard bits [0-5] is Differentiated Services Code Point (DSCP) and the remaining two bits [6-7] are still unused. The DSCP field is pretty much used the same as in how the ToS field was used before, to mark what kind of service this packet should be treated like if the router in question makes any difference between them. One big change is that a device must ignore the unused bits to be fully RFC 2474 compliant, which means we get rid of the previous hassle as explained previously, as long as the device creators follow this RFC.

ToS 字段的第三次（也是最后一次）更改是，之前未使用的两个位用于 ECN（显式拥塞通知），如 RFC 3168 中所定义。ECN 用于让端节点了解路由器拥塞情况，在它实际开始丢弃数据包之前，以便终端节点能够在路由器实际需要开始丢弃数据之前减慢其数据传输速度。以前，丢弃数据是路由器告知其过载的唯一方式，并且端节点必须为每个丢弃的数据包缓慢重新启动，然后再次缓慢恢复速度。这两个位被命名为 ECT（支持 ECN 传输）和 CE（经历拥塞）代码点。

The third, and almost last, change of the ToS field was when the two, previously, unused bits were used for ECN (Explicit Congestion Notification), as defined in RFC 3168. ECN is used to let the end nodes know about a routers congestion, before it actually starts dropping packets, so that the end nodes will be able to slow down their data transmissions, before the router actually needs to start dropping data. Previously, dropping data was the only way that a router had to tell that it was overloaded, and the end nodes had to do a slow restart for each dropped packet, and then slowly gather up speed again. The two bits are named ECT (ECN Capable Transport) and CE (Congestion Experienced) codepoints.

整个混乱的最后一个迭代是 RFC 3260，它为 DiffServ 系统的使用提供了一些新的术语和说明。除了术语之外，它不涉及太多新的更新或更改。RFC 还用于澄清开发人员之间讨论的一些要点。

The final iteration of the whole mess is RFC 3260 which gives some new terminology and clarifications to the usage of the DiffServ system. It doesn't involve too many new updates or changes, except in the terminology. The RFC is also used to clarify some points that were discussed between developers.

总长度 - 位 16 - 31。该字段告诉我们数据包有多大（以八位字节为单位），包括标头和所有内容。单个数据包的最大大小为 65535 个八位位组或字节。最小数据包大小为 576 字节，不关心数据包是否分片到达。根据 RFC 791，仅在可以保证主机可以接收数据包的情况下，才建议发送大于此限制的数据包。但是，目前大多数网络都以 1500 字节数据包大小运行。这包括几乎所有以太网连接和大多数互联网连接。

Total Length - bits 16 - 31. This field tells us how large the packet is in octets, including headers and everything. The maximum size is 65535 octets, or bytes, for a single packet. The minimum packet size is 576 bytes, not caring if the packet arrives in fragments or not. It is only recommended to send larger packets than this limit if it can be guaranteed that the host can receive it, according to RFC 791. However, these days most networks runs at 1500 byte packet size. This includes almost all ethernet connections, and most Internet connections.

标识 - 位 32 - 46。该字段用于帮助重组分段数据包。

Identification - bits 32 - 46. This field is used in aiding the reassembly of fragmented packets.

标志 - 位 47 - 49。该字段包含一些与分段相关的杂项标志。第一个位被保留，但仍然没有使用，并且必须设置为0。如果数据包可能被分片，则第二个位设置为0，如果数据包不能被分片，则设置为1。如果这是最后一个片段，则第三个也是最后一个位可以设置为 0，如果同一数据包有更多片段，则可以设置为 1。

Flags - bits 47 - 49. This field contains a few miscellaneous flags pertaining to fragmentation. The first bit is reserved, but still not used, and must be set to 0. The second bit is set to 0 if the packet may be fragmented, and to 1 if it may not be fragmented. The third and last bit can be set to 0 if this was the last fragment, and 1 if there are more fragments of this same packet.

片段偏移 - 位 50 - 63。片段偏移字段显示此数据包属于数据报中的位置。片段以 64 位计算，第一个片段的偏移量为零。

Fragment Offset - bits 50 - 63. The fragment offset field shows where in the datagram that this packet belongs. The fragments are calculated in 64 bits, and the first fragment has offset zero.

生存时间 - 位 64 - 72。TTL 字段告诉我们数据包可以生存多长时间，或者更确切地说，它可以通过互联网经过多少“跳”。每个接触数据包的进程都必须从 TTL 字段中删除一个点，如果 TTL 达到零，则必须破坏并丢弃整个数据包。这基本上用作安全触发器，以便数据包不会最终陷入一台或多台主机之间的不可控循环中。破坏后，主机应向发送者返回 ICMP 超时消息。

Time to live - bits 64 - 72. The TTL field tells us how long the packet may live, or rather how many "hops" it may take over the Internet. Every process that touches the packet must remove one point from the TTL field, and if the TTL reaches zero, the whole packet must be destroyed and discarded. This is basically used as a safety trigger so that a packet may not end up in an uncontrollable loop between one or several hosts. Upon destruction the host should return an ICMP Time exceeded message to the sender.

协议 - 位 73 - 80。在该字段中指示下一层的协议。例如，这可以是 TCP、UDP 或 ICMP 等。所有这些号码均由互联网号码分配机构定义。所有号码都可以在互联网号码分配机构的主页上找到。

Protocol - bits 73 - 80. In this field the protocol of the next level layer is indicated. For example, this may be TCP, UDP or ICMP among others. All of these numbers are defined by the Internet Assigned Numbers Authority. All numbers can befound on their homepage Internet Assigned Numbers Authority.

标头校验和 - 位 81 - 96。这是数据包的 IP 标头的校验和。该字段在每个更改标头的主机上重新计算，这意味着数据包遍历的几乎每个主机，因为它们最常更改标头数据包 TTL 字段或其他字段。

Header checksum - bits 81 - 96. This is a checksum of the IP header of the packet.This field is recomputed at every host that changes the header, which means pretty much every host that the packet traverses over, since they most often change the packets TTL field or some other.

源地址 - 位 97 - 128。这是源地址字段。它通常写成 4 个八位位组，从二进制转换为十进制数字，中间有点。例如，127.0.0.1。该字段让接收者知道数据包来自哪里。

Source address - bits 97 - 128. This is the source address field. It is generally written in 4 octets, translated from binary to decimal numbers with dots in between. That is for example, 127.0.0.1. The field lets the receiver know where the packet came from.

目标地址 - 位 129 - 160。目标地址字段包含目标地址，令人惊讶的是，它的格式与源地址相同。

Destination address - bits 129 - 160. The destination address field contains the destination address, and what a surprise, it is formatted the same way as the source address.

选项 - 位 161 - 192 <> 478。选项字段不是可选的，正如它听起来的那样。实际上，这是 IP 标头中较复杂的字段之一。选项字段在标头中包含不同的可选设置，例如 Internet 时间戳、SACK 或记录路由路由选项。由于这些选项都是可选的，因此选项字段可以具有不同的长度，因此整个 IP 标头也可以具有不同的长度。然而，由于我们总是以 32 位字计算 IP 标头，因此我们必须始终以偶数（即 32 的倍数）结束标头。该字段可能包含零个或多个选项。

Options - bits 161 - 192 <> 478. The options field is not optional, as it may sound. Actually, this is one of the more complex fields in the IP header. The options field contains different optional settings within the header, such as Internet timestamps, SACK or record route route options. Since these options are all optional, the Options field can have different lengths, and hence the whole IP header. However, since we always calculate the IP header in 32 bit words, we must always end the header on an even number, that is the multiple of 32. The field may contain zero or more options.

选项字段以一个简短的 8 位字段开头，让我们知道数据包中使用了哪些选项。TCP 选项附录中的TCP 选项表中列出了所有选项。有关不同选项的更多信息，请阅读相应的 RFC。有关 IP 选项的更新列表，请查看Internet 号码分配机构。

The options field starts with a brief 8 bit field that lets us know which options are used in the packet. The options are all listed in the TCP Options table, in the TCP options appendix. For more information about the different options, read the proper RFC's. For an updated listing of the IP options, check at Internet Assigned Numbers Authority.

填充 - 位变量。这是一个填充字段，用于使标头以偶数 32 位边界结束。该字段必须始终设置为零，直到最后。

Padding - bits variable. This is a padding field that is used to make the header end at an even 32 bit boundary. The field must always be set to zeroes straight through to the end.

TCP特性

TCP characteristics

TCP 协议位于 IP 协议之上。它是一个有状态的协议，具有内置功能来查看数据是否被另一端主机正确接收。TCP协议的主要目标是保证数据可靠地接收和发送，保证数据在网际层和应用层之间正确传输，保证分组数据到达应用层的正确程序，保证数据的正确传输。以正确的顺序到达程序。所有这些都可以通过数据包的 TCP 标头实现。

The TCP protocol resides on top of the IP protocol. It is a stateful protocol and has built-in functions to see that the data was received properly by the other end host. The main goals of the TCP protocol is to see that data is reliably received and sent, that the data is transported between the Internet layer and Application layer correctly, and that the packet data reaches the proper program in the application layer, and that the data reaches the program in the right order. All of this is possible through the TCP headers of the packet.

TCP 协议将数据视为具有开始和停止信号的连续数据流。指示新流正在等待打开的信号在 TCP 中称为 SYN 三向握手，由一个设置了 SYN 位的数据包组成。然后另一端用 SYN/ACK 或 SYN/RST 进行应答，让客户端分别知道连接是被接受还是被拒绝。如果客户端收到 SYN/ACK 数据包，它会再次回复，这次是 ACK 数据包。至此，整个连接就建立起来了，可以发送数据了。在此初始握手期间，还将协商将在 TCP 连接的其余部分中使用的所有特定选项，例如 ECN、SACK 等。

The TCP protocol looks at data as an continuous data stream with a start and a stop signal. The signal that indicates that a new stream is waiting to be opened is called a SYN three-way handshake in TCP, and consists of one packet sent with the SYN bit set. The other end then either answers with SYN/ACK or SYN/RST to let the client know if the connection was accepted or denied, respectively. If the client receives an SYN/ACK packet, it once again replies, this time with an ACK packet. At this point, the whole connection is established and data can be sent. During this initial handshake, all of the specific options that will be used throughout the rest of the TCP connection is also negotiated, such as ECN, SACK, etcetera.

当数据流处于活动状态时，我们有进一步的机制来查看数据包实际上已被另一端正确接收。这是TCP的可靠性部分。这是通过使用数据包中的序列号以简单的方式完成的。每次发送数据包时，我们都会为序列号赋予一个新值，当另一端收到数据包时，它会向数据发送方发送一个 ACK​​ 数据包。ACK 数据包确认数据包已正确接收。序列号还确保数据包以良好的顺序插入到数据流中。

While the datastream is alive, we have further mechanisms to see that the packets are actually received properly by the other end. This is the reliability part of TCP. This is done in a simple way, using a Sequence number in the packet. Every time we send a packet, we give a new value to the Sequence number, and when the other end receives the packet, it sends an ACK packet back to the data sender. The ACK packet acknowledges that the packet was received properly. The sequence number also sees to it that the packet is inserted into the data stream in a good order.

连接关闭后，可以通过从任一端点发送 FIN 数据包来完成。然后另一端通过发送 FIN/ACK 数据包进行响应。FIN发送端就不能再发送任何数据，但另一端仍然可以完成数据发送。一旦第二个端点希望完全关闭连接，它就会向最初关闭的端点发送 FIN 数据包，而另一个端点则回复 FIN/ACK 数据包。整个过程完成后，连接就会正确断开。

Once the connection is closed, this is done by sending a FIN packet from either end-point. The other end then responds by sending a FIN/ACK packet. The FIN sending end can then no longer send any data, but the other end-point can still finish sending data. Once the second end-point wishes to close the connection totally, it sends a FIN packet back to the originally closing end-point, and the other end-point replies with a FIN/ACK packet. Once this whole procedure is done, the connection is torn down properly.

正如您稍后将看到的，TCP 标头也包含校验和。校验和由数据包的简单散列组成。通过这个哈希值，我们可以相当高精度地查看数据包在主机之间传输期间是否以任何方式被损坏。

As you will also later see, the TCP headers contain a checksum as well. The checksum consists of a simple hash of the packet. With this hash, we can with rather high accuracy see if a packet has been corrupted in any way during transit between the hosts.

TCP 标头

TCP headers

TCP 标头必须能够执行上述所有任务。我们已经解释了某些标头的使用时间和地点，但还有其他一些领域我们还没有深入探讨。下面您可以看到完整的 TCP 标头集的图像。如您所见，它的格式为每行 32 位字。

The TCP headers must be able to perform all of the tasks above. We have already explained when and where some of the headers are used, but there are still other areas that we haven't touched very deeply at. Below you see an image of the complete set of TCP headers. It is formatted in 32 bit words per row, as you can see.

源端口 - 位 0 - 15。这是数据包的源端口。源端口最初直接绑定到发送系统上的进程。今天，我们在 IP 地址以及目标和源端口之间使用哈希来实现这种唯一性，我们可以将其绑定到单个应用程序或程序。

Source port - bit 0 - 15. This is the source port of the packet. The source port was originally bound directly to a process on the sending system. Today, we use a hash between the IP addresses, and both the destination and source ports to achieve this uniqueness that we can bind to a single application or program.

目标端口 - 位 16 - 31。这是 TCP 数据包的目标端口。正如源端口一样，它最初直接绑定到接收系统上的进程。如今，我们使用了哈希值，这使得我们可以同时拥有更多的开放连接。当收到数据包时，在返回原始发送主机的回复中，目标端口和源端口会颠倒过来，因此目标端口现在是源端口，源端口是目标端口。

Destination port - bit 16 - 31. This is the destination port of the TCP packet. Just as with the source port, this was originally bound directly to a process on the receiving system. Today, a hash is used instead, which allows us to have more open connections at the same time. When a packet is received, the destination and source ports are reversed in the reply back to the originally sending host, so that destination port is now source port, and source port is destination port.

序列号 - 位 32 - 63。序列号字段用于在每个 TCP 数据包上设置一个编号，以便 TCP 流可以正确排序（例如，数据包以正确的顺序结束）。然后，序列号在 ACK 字段中返回，以确认数据包已正确接收。

Sequence Number - bit 32 - 63. The sequence number field is used to set a number on each TCP packet so that the TCP stream can be properly sequenced (e.g., the packets winds up in the correct order). The Sequence number is then returned in the ACK field to ackonowledge that the packet was properly received.

确认编号 - 位 64 - 95。当我们确认主机收到的特定数据包时，将使用此字段。例如，我们收到一个设置了一个序列号的数据包，如果该数据包一切正常，我们会回复一个 ACK​​ 数据包，其中确认号设置为与原始序列号相同。

Acknowledgment Number - bit 64 - 95. This field is used when we acknowledge a specific packet a host has received. For example, we receive a packet with one Sequence number set, and if everything is okey with the packet, we reply with an ACK packet with the Acknowledgment number set to the same as the original Sequence number.

数据偏移 - 位 96 - 99。该字段指示 TCP 标头的长度以及数据包的数据部分实际开始的位置。它设置为 4 位，并以 32 位字测量 TCP 标头。即使设置了不同的选项，标头也应始终以偶数 32 位边界结束。这要归功于 TCP 标头最末尾的填充字段。

Data Offset - bit 96 - 99. This field indicates how long the TCP header is, and where the Data part of the packet actually starts. It is set with 4 bits, and measures the TCP header in 32 bit words. The header should always end at an even 32 bit boundary, even with different options set. This is possible thanks to the Padding field at the very end of the TCP header.

保留 - 位 100 - 103。这些位保留供将来使用。在 RFC 793 中，这还包括 CWR 和 ECE 位。根据 RFC 793 位 100-105（即，此字段以及 CWR 和 ECE 字段）必须设置为零才能完全兼容。后来，当我们开始引入ECN时，这引起了很多麻烦，因为许多互联网设备（例如防火墙和路由器）在设置它们后会丢弃数据包。截至撰写本文时，情况仍然如此。

Reserved - bit 100 - 103. These bits are reserved for future usage. In RFC 793 this also included the CWR and ECE bits. According to RFC 793 bit 100-105 (i.e., this and the CWR and ECE fields) must be set to zero to be fully compliant. Later on, when we started introducing ECN, this caused a lot of troubles because a lot of Internet appliances such as firewalls and routers dropped packets with them set. This is still true as of writing this.

CWR - 位 104。该位是在 RFC 3268 中添加的，并由 ECN 使用。CWR是Congestion Window Decred的缩写，用于数据发送端通知接收端拥塞窗口已经减小。当拥塞窗口减少时，我们在每个时间单位发送更少的数据，以便能够应对总网络负载。

CWR - bit 104. This bit was added in RFC 3268 and is used by ECN. CWR stands for Congestion Window Reduced, and is used by the data sending part to inform the receiving part that the congestion window has been reduced. When the congestion window is reduced, we send less data per timeunit, to be able to cope with the total network load.

ECE - 位 105。该位也是随 RFC 3268 添加的，并由 ECN 使用。ECE 代表 ECN 回声。接收方主机上的 TCP/IP 堆栈使用它来让发送方主机知道它已收到 CE 数据包。同样的事情也适用于此，对于 CWR 位，它最初是保留字段的一部分，因此，如果这些字段包含除零以外的任何内容，某些网络设备将简单地丢弃数据包。不幸的是，对于许多电器来说，实际上仍然如此。

ECE - bit 105. This bit was also added with RFC 3268 and is used by ECN. ECE stands for ECN Echo. It is used by the TCP/IP stack on the receiver host to let the sending host know that it has received an CE packet. The same thing applies here, as for the CWR bit, it was originally a part of the reserved field and because of this, some networking appliances will simply drop the packet if these fields contain anything else than zeroes. This is actually still true for a lot of appliances unfortunately.

URG - 位 106。该字段告诉我们是否应该使用紧急指针字段。如果设置为 0，则不使用紧急指针，如果设置为 1，则使用紧急指针。

URG - bit 106. This field tells us if we should use the Urgent Pointer field or not. If set to 0, do not use Urgent Pointer, if set to 1, do use Urgent pointer.

ACK - 位 107。该位设置为数据包，表示这是对我们收到的另一个包含数据的数据包的回复。始终发送确认数据包以表明我们实际上已收到数据包，并且它不包含任何错误。如果该位被设置，原始数据发送方将检查确认号以查看哪个数据包被实际确认，然后将其从缓冲区中转储。

ACK - bit 107. This bit is set to a packet to indicate that this is in reply to another packet that we received, and that contained data. An Acknowledgment packet is always sent to indicate that we have actually received a packet, and that it contained no errors. If this bit is set, the original data sender will check the Acknowledgment Number to see which packet is actually acknowledged, and then dump it from the buffers.

PSH - 位 108。PUSH 标志用于告诉任何中间主机上的 TCP 协议将数据发送到实际用户，包括接收主机上的 TCP 实现。这将推送所有数据，无论已推送的 TCP 窗口在何处或多少。

PSH - bit 108. The PUSH flag is used to tell the TCP protocol on any intermediate hosts to send the data on to the actual user, including the TCP implementation on the receiving host. This will push all data through, unregardless of where or how much of the TCP Window that has been pushed through yet.

RST - 位 109。设置 RESET 标志以告诉另一端拆除 TCP 连接。这是在几种不同的情况下完成的，主要原因是连接由于某种原因而崩溃，如果连接不存在，或者数据包在某种程度上是错误的。

RST - bit 109. The RESET flag is set to tell the other end to tear down the TCP connection. This is done in a couple of different scenarios, the main reasons being that the connection has crashed for some reason, if the connection does not exist, or if the packet is wrong in some way.

SYN - 位 110。SYN（或同步序列号）在连接的初始建立期间使用。它在连接的两个实例中设置，即打开连接的初始数据包和回复 SYN/ACK 数据包。它永远不应该在这些实例之外使用。

SYN - bit 110. The SYN (or Synchronize sequence numbers) is used during the initial establishment of a connection. It is set in two instances of the connection, the initial packet that opens the connection, and the reply SYN/ACK packet. It should never be used outside of those instances.

FIN - 位 111。FIN 位指示发送 FIN 位的主机没有更多数据要发送。当另一端看到 FIN 位时，会回复 FIN/ACK。完成此操作后，最初发送 FIN 位的主机将无法再发送任何数据。但另一端可以继续发送数据，直到发送完毕，然后会发回FIN数据包，并等待最终的FIN/ACK，之后连接将转为CLOSED状态。

FIN - bit 111. The FIN bit indicates that the host that sent the FIN bit has no more data to send. When the other end sees the FIN bit, it will reply with a FIN/ACK. Once this is done, the host that originally sent the FIN bit can no longer send any data. However, the other end can continue to send data until it is finished, and will then send a FIN packet back, and wait for the final FIN/ACK, after which the connection is sent to a CLOSED state.

窗口 - 位 112 - 127。接收主机使用窗口字段来告诉发送方接收方当前允许多少数据。这是通过发回 ACK 来完成的，其中包含我们要确认的序列号，然后窗口字段包含发送主机在接收下一个 ACK​​ 数据包之前可以使用的最大接受序列号。下一个ACK数据包将更新发送方可以使用的接受窗口。

Window - bit 112 - 127. The Window field is used by the receiving host to tell the sender how much data the receiver permits at the moment. This is done by sending an ACK back, which contains the Sequence number that we want to acknowledge, and the Window field then contains the maximum accepted sequence numbers that the sending host can use before he receives the next ACK packet. The next ACK packet will update accepted Window which the sender may use.

校验和 - 位 128 - 143。该字段包含整个 TCP 标头的校验和。它是头部中每个16位字的反码和的反码。如果标头未在 16 位边界上结束，则附加位将设置为零。计算校验和时，校验和字段设置为零。校验和还包含一个 96 位伪标头，其中包含目标地址、源地址、协议和 TCP 长度。这是为了额外的安全性。

Checksum - bit 128 - 143. This field contains the checksum of the whole TCP header. It is a one's complement of the one's complement sum of each 16 bit word in the header. If the header does not end on a 16 bit boundary, the additional bits are set to zero. While the checksum is calculated, the checksum field is set to zero. The checksum also covers a 96 bit pseudoheader containing the Destination-, Source-address, protocol, and TCP length. This is for extra security.

紧急指针 - 位 144 - 159。这是一个指向被视为紧急的数据末尾的指针。如果连接中有重要数据需要接收端尽快处理，发送方可以设置URG标志并设置紧急指针来指示紧急数据在哪里结束。

Urgent Pointer - bit 144 - 159. This is a pointer that points to the end of the data which is considered urgent. If the connection has important data that should be processed as soon as possible by the receiving end, the sender can set the URG flag and set the Urgent pointer to indicate where the urgent data ends.

选项 - 位 160 - **。选项字段是一个可变长度字段，包含我们可能想要使用的可选标头。基本上，该字段始终包含 3 个子字段。初始字段告诉我们选项字段的长度，第二个字段告诉我们使用了哪些选项，然后我们就有了实际的选项。所有 TCP 选项的完整列表可以在TCP 选项中找到。

Options - bit 160 - **. The Options field is a variable length field and contains optional headers that we may want to use. Basically, this field contains 3 subfields at all times. An initial field tells us the length of the Options field, a second field tells us which options are used, and then we have the actual options. A complete listing of all the TCP Options can be found in TCP options.

填充 - 位**。填充字段填充 TCP 标头，直到整个标头以 32 位边界结束。这可确保数据包的数据部分从 32 位边界开始，并且数据包中不会丢失任何数据。填充始终仅由零组成。

Padding - bit **. The padding field pads the TCP header until the whole header ends at a 32-bit boundary. This ensures that the data part of the packet begins on a 32-bit boundary, and no data is lost in the packet. The padding always consists of only zeros.

UDP特性

UDP characteristics

用户数据报协议 (UDP) 是 IP 协议之上的一个非常基本且简单的协议。它的开发是为了允许非常简单的数据传输，无需任何类型的错误检测，并且它是无状态的。然而，它非常适合查询/响应类型的应用程序，例如 DNS 等，因为我们知道，除非我们从 DNS 服务器获得答复，否则查询会在某个地方丢失。有时，也可能值得使用 UDP 协议而不是 TCP，例如当我们只想进行错误/丢失检测但不关心数据包的排序时。这消除了来自 TCP 协议的一些开销。我们还可以做其他事情，在 UDP 之上制定我们自己的协议，仅包含排序，但不包含错误或丢失检测。

The User Datagram Protocol (UDP) is a very basic and simple protocol on top of the IP protocol. It was developed to allow for very simple data transmission without any error detection of any kind, and it is stateless. However, it is very well fit for query/response kind of applications, such as for example DNS, et cetera, since we know that unless we get a reply from the DNS server, the query was lost somewhere. Sometimes it may also be worth using the UDP protocol instead of TCP, such as when we want only error/loss detection but don't care about sequencing of the packets. This removes some overhead that comes from the TCP protocol. We may also do the other thing around, make our own protocol on top of UDP that only contains sequencing, but no error or loss detection.

UDP 协议在RFC 768 - 用户数据报协议中指定。这是一个非常简短的 RFC，非常适合像这样的简单协议。

The UDP protocol is specified in RFC 768 - User Datagram Protocol. It is a very short and brief RFC, which fits a simple protocol like this very well.

UDP 标头

UDP headers

UDP报头可以说包含了一个非常基本且简化的TCP报头。它包含目标端口、源端口、标头长度和校验和，如下图所示。

The UDP header can be said to contain a very basic and simplified TCP header. It contains destination-, source-ports, header length and a checksum as seen in the image below.

源端口 - 位 0-15。这是数据包的源端口，描述了应答数据包应发送到的位置。如果不适用，实际上可以将其设置为零。例如，有时我们不需要回复数据包，然后可以将数据包设置为源端口零。在大多数实现中，它被设置为某个端口号。

Source port - bit 0-15. This is the source port of the packet, describing where a reply packet should be sent. This can actually be set to zero if it doesn't apply. For example, sometimes we don't require a reply packet, and the packet can then be set to source port zero. In most implementations, it is set to some port number.

目标端口 - 位 16-31。数据包的目的端口。这对于所有数据包都是必需的，而不是数据包的源端口。

Destination port - bit 16-31. The destination port of the packet. This is required for all packets, as opposed to the source port of a packet.

长度 - 位 32-47。长度字段指定整个数据包的长度（以八位字节为单位），包括标头和数据部分。最短的数据包长度可为 8 个八位位组。

Length - bit 32-47. The length field specifies the length of the whole packet in octets, including header and data portions. The shortest possible packet can be 8 octets long.

校验和 - 位 48-63。校验和与 TCP 标头中使用的校验和相同，只是它包含不同的数据集。换句话说，它是IP报头部分、整个UDP报头、UDP数据的补码和的补码，并在必要时在末尾补零。

Checksum - bit 48-63. The checksum is the same kind of checksum as used in the TCP header, except that it contains a different set of data. In other words, it is a one's complement of the one's complement sum of parts of the IP header, the whole UDP header, theUDP data and padded with zeroes at the end when necessary.

ICMP 特性

ICMP characteristics

ICMP 消息用于主机到主机或主机到网关之间的基本错误报告。在网关到网关之间，通常应使用称为网关到网关协议 (GGP) 的协议来进行错误报告。正如我们已经讨论过的，IP 协议并不是为完美的错误处理而设计的，但 ICMP 消息解决了这些问题的某些部分。从一个角度来看，最大的问题是 ICMP 消息的标头相当复杂，并且各个消息之间略有不同。然而，大多数时候从过滤的角度来看这并不是一个大问题。

ICMP messages are used for a basic kind of error reporting between host to host, or host to gateway. Between gateway to gateway, a protocol called Gateway to Gateway protocol (GGP) should normally be used for error reporting. As we have already discussed, the IP protocol is not designed for perfect error handling, but ICMP messages solves some parts of these problems. The big problem from one standpoint is that the headers of the ICMP messages are rather complicated, and differ a little bit from message to message. However, this will not be a big problem from a filtering standpoint most of the time.

基本形式是消息包含标准IP头、类型、代码和校验和。所有 ICMP 消息都包含这些字段。类型指定该数据包是什么类型的错误或回复消息，例如目的地不可达、回显、回显回复或重定向消息。如有必要，代码字段指定更多信息。如果数据包的类型为“目的地不可达”，则此代码字段上有多个可能的值，例如网络不可达、主机不可达或端口不可达。校验和只是整个数据包的校验和。

The basic form is that the message contains the standard IP header, type, code and a checksum. All ICMP messages contains these fields. The type specifies what kind of error or reply message this packet is, such as for example destination unreachable, echo, echo reply, or redirect message. The code field specifies more information, if necessary. If the packet is of type destination unreachable, there are several possible values on this code field such as network unreachable, host unreachable, or port unreachable. The checksum is simply a checksum for the whole packet.

您可能已经注意到，我明确提到了 ICMP 数据包的 IP 标头。这样做是因为实际的 IP 标头是 ICMP 数据包的组成部分，并且 ICMP 协议在某种意义上与 IP 协议处于同一级别。ICMP 确实使用 IP 协议，就好像它是更高级别的协议一样，但同时又不是。ICMP 是IP 的一个组成部分，并且ICMP 必须在每个IP 实现中实现。

As you may have noticed, I mentioned the IP header explicitly for the ICMP packet. This was done since the actual IP header is an integral part of the ICMP packet, and the ICMP protocol lives on the same level as the IP protocol in a sense. ICMP does use the IP protocol as if it where a higher level protocol, but at the same time not. ICMP is an integral part of IP, and ICMP must be implemented in every IP implementation.

ICMP 标头

ICMP headers

如前所述，不同 ICMP 类型的标头略有不同。大多数 ICMP 类型都可以按其标头进行分组。因此，我们将首先讨论基本标头形式，然后查看应讨论的每组类型的具体细节。

As already explained, the headers differs a little bit from ICMP type to ICMP type. Most of the ICMP types are possible to group by their headers. Because of this, we will discuss the basic header form first, and then look at the specifics for each group of types that should be discussed.

所有数据包都包含本章前面讨论的 IP 标头中的一些基本值。之前已经对标题进行了一定的讨论，因此这只是标题的简短列表，以及一些关于它们的注释。

All packets contain some basic values from the IP headers discussed previously in this chapter. The headers have previously been discussed at some length, so this is just a short listing of the headers, with a few notes about them.

• 版本 - 应始终设置为 4。

• Version - This should always be set to 4.

• Internet 标头长度 - 32 位字中的标头长度。

• Internet Header Length - The length of the header in 32 bit words.

• 服务类型 - 参见上文。该值应设置为 0，因为这是根据RFC 792 - Internet Control Message Protocol 的唯一合法设置。

• Type of Service - See above. This should be set to 0, as this is the only legit setting according to RFC 792 - Internet Control Message Protocol.

• 总长度 - 数据包的标头和数据部分的总长度，以八位位组计算。

• Total Length - Total length of the header and data portion of the packet, counted in octets.

• 标识、标志和片段偏移量 - 从 IP 协议中剥离。

• Identification , Flags and Fragment offsets - Ripped from the IP protocol.

• 生存时间 - 该数据包将存活多少跳。

• Time To Live - How many hops this packet will survive.

• 协议 - 正在使用哪个版本的 ICMP（应始终为 1）。

• Protocol - which version of ICMP is being used (should always be 1).

• 标头校验和 - 请参阅 IP 说明。

• Header Checksum - See the IP explanation.

• 源地址 - 发送数据包的源地址。这并不完全正确，因为数据包可以有另一个源地址，而不是位于相关机器上的源地址。如果是这样，将注明可以产生此效果的 ICMP 类型。

• Source Address - The source address from whom the packet was sent. This is not entirely true, since the packet can have another source address, than that which is located on the machine in question. The ICMP types that can have this effect will be noted if so.

• 目标地址 - 数据包的目标地址。

• Destination Address - The destination address of the packet.

还有一些所有 ICMP 类型都使用的新标头。新的标题如下，这次还有一些关于它们的注释：

There are also a couple of new headers that are used by all of the ICMP types. The new headers are as follows, this time with a few more notes about them:

• 类型 - 类型字段包含数据包的 ICMP 类型。这对于不同的 ICMP 类型总是不同的。例如，ICMP 目标不可达数据包将设置为类型 3。有关不同 ICMP 类型的完整列表，请参阅ICMP 类型附录。该字段总共包含 8 位。

• Type - The type field contains the ICMP type of the packet. This is always different from ICMP type to type. For example ICMP Destination Unreachable packets will have a type 3 set to it. For a complete listing of the different ICMP types, see the ICMP types appendix. This field contains 8 bits total.

• 代码 - 所有 ICMP 类型也可以包含不同的代码。有些类型只有一个代码，而其他类型则有多个可以使用的代码。例如，ICMP 目标无法到达（类型 3）可以至少设置代码 0、1、2、3、4 或 5。每个代码在该上下文中都有不同的含义。有关不同代码的完整列表，请参阅ICMP 类型附录。该字段总共有 8 位长度。我们将在本节后面更详细地讨论每种类型的不同代码。

• Code - All ICMP types can contain different codes as well. Some types only have a single code, while others have several codes that they can use. For example, the ICMP Destination Unreachable (type 3) can have at least code 0, 1, 2, 3, 4 or 5 set. Each code has a different meaning in that context then. For a complete listing of the different codes, see the ICMP types appendix. This field is 8 bits in length, total. We will discuss the different codes a little bit more in detail for each type later on in this section.

• 校验和 - 校验和是一个 16 位字段，包含从 ICMP 类型开始向下的标头的补码。计算校验和时，校验和字段应设置为零。

• Checksum - The Checksum is a 16 bit field containing a one's complement of the ones complement of the headers starting with the ICMP type and down. While calculating the checksum, the checksum field should be set to zero.

此时，不同数据包的标头也开始看起来不同。我们将一一描述最常见的 ICMP 类型，并简要讨论其标头和不同的代码。

At this point the headers for the different packets start to look different also. We will describe the most common ICMP Types one by one, with a brief discussion of its headers and different codes.

---

源抑制

Source Quench

可以发送源抑制数据包，以告诉数据包或数据包流的原始源在继续发送数据时放慢速度。请注意，数据包所经过的网关或目标主机也可以保持安静并默默地丢弃数据包，而不是发送任何源抑制数据包。

A source quench packet can be sent to tell the originating source of a packet or stream of packets to slow down when continuing to send data. Note that gateway or destination host that the packets traverses can also be quiet and silently discard the packets, instead of sending any source quench packets.

除了数据部分外，该数据包不包含任何额外的标头，数据部分包含互联网标头以及原始数据报的 64 位。这用于将源抑制消息与当前正在通过网关发送数据或向目标主机发送数据的正确进程进行匹配。

This packet contains no extra header except the data portion, which contains the internet header plus 64 bits of the original data datagram. This is used to match the source quench message to the correct process, which is currently sending data through the gateway or to the destination host.

所有源抑制数据包的 ICMP 类型均设置为 4。除了 0 之外，它们没有任何代码。

All source quench packets have their ICMP types set to 4. They have no codes except 0.

如今，有几种新的可能方法可以通知发送和接收主机网关或目标主机过载。例如，一种方法是 ECN（显式拥塞通知）系统。 Today, there are a couple of new possible ways of notifying the sending and receiving host that a gateway or destination host is overloaded. One way for example is the ECN (Explicit Congestion Notification) system.

SCTP特点

SCTP Characteristics

流控制传输协议 (SCTP) 是游戏中相对较新的协议，但由于它的使用量不断增长并且补充了 TCP 和 UDP 协议，因此我选择添加有关它的这一部分。它具有比 TCP 更高的可靠性，同时协议头的开销更低。

Stream Control Transmission Protocol (SCTP) is a relatively new protocol in the game, but since it is growing in usage and complements the TCP and UDP protocols, I have chosen to add this section about it. It has an even higher reliability than TCP, and at the same time a lower overhead from protocol headers.

SCTP 有一些非常有趣的功能。对于那些希望了解更多信息的人，请阅读 RFC 3286 - 流控制传输协议简介和RFC 2960 - 流控制传输协议文档。第一篇文档是 SCTP 的介绍，对于那些仍然需要更多信息的人来说应该非常有趣。第二个文档是协议的实际规范，除非您正在为协议进行开发或真的感兴趣，否则它可能不太有趣。

SCTP has a couple of very interesting features that can be interesting. For those who wish to learn more about this, read the RFC 3286 - An Introduction to the Stream Control Transmission Protocol and RFC 2960 - Stream Control Transmission Protocol document. The first document is an introduction to SCTP and should be very interesting to people who are still in need of more information. The second document is the actual specification for the protocol, which might be less interesting unless you are developing for the protocol or are really interested.

该协议最初是为 IP 电话或 IP 语音 (VoIP) 开发的，因此具有一些非常有趣的属性。工业级 VoIP 需要非常高的可靠性，这意味着必须在系统中内置大量弹性来处理不同类型的问题。以下列出了 SCTP 的基本功能。

The protocol was originally developed for Telephony over IP, or Voice over IP (VoIP), and has some very interesting attributes due to this. Industry grade VoIP requires very high reliability for one, and this means that a lot of resilience has to be built into the system to handle different kind of problems. The following is a list of the basic features of SCTP.

• 具有多播属性的单播。这意味着它是一种点对点协议，但能够在同一终端主机上使用多个地址。换句话说，它可以使用不同的路径到达最终主机。相比之下，如果传输路径中断，TCP 就会中断，除非 IP 协议对其进行纠正。

• Unicast with Multicast properties. This means it is a point-to-point protocol but with the ability to use several addresses at the same end host. It can in other words use different paths to reach the end host. TCP in comparison breaks if the transport path breaks, unless the IP protocol corrects it.

• 可靠的传输。它使用校验和和 SACK 来检测损坏、损坏、丢弃、重复和重新排序的数据。然后它可以根据需要重新传输数据。这与 TCP 几乎相同，但 SCTP 在重新排序数据时更具弹性，并且允许更快的拾取。

• Reliable transmission. It uses checksums and SACK to detect corrupted, damaged, discarded, duplicated and reordered data. It can then retransmit data as necessary. This is pretty much the same as TCP, but SCTP is more resilient when it comes to reordered data and allows for faster pickups.

• 消息导向。每条消息都可以被构建，因此您可以密切关注数据流的结构和顺序。TCP是面向字节的，你得到的只是字节流，内部不同数据之间没有任何顺序。换句话说，您需要 TCP 中的额外抽象层。

• Message oriented. Each message can be framed and hence you can keep tabs on the structure and order of the datastream. TCP is byte oriented and all you get is a stream of bytes without any order between different data inside. You need an extra layer of abstraction in TCP in other words.

• 速率自适应。它的开发是为了与 TCP 进行带宽合作并共存。它与 TCP 一样根据网络负载条件进行扩展和缩减。它还具有相同的算法，可以在数据包丢失时缓慢启动。还支持 ECN。

• Rate adaptive. It is developed to cooperate and co-exist with TCP for bandwidth. It scales up and down based on network load conditions just the same as TCP. It also has the same algorithms for slow starting when packets where lost. ECN is also supported.

• 多归属。如前所述，它能够直接在协议中设置不同的终端节点，因此不必依赖 IP 层来实现弹性。

• Multi-homing. As previously mentioned, it is able to set up different end nodes directly in the protocol, and hence doesn't have to rely on the IP layer for resilience.

• 多流。这允许同一流内同时存在多个流。因此得名流控制传输协议。例如，可以打开单个流来下载单个网页，然后可以在同一流中同时下载所有图像和 html 文档。或者为什么不使用数据库协议来创建单独的控制流，然后使用多个流同时接收不同查询的输出。

• Multi-streaming. This allows for multiple simultaneous streams inside the same stream. Hence the name Stream Control Transmission Protocol. A single stream can for example be opened to download a single webpage, and all the images and html documents can then be downloaded within the same stream simultaneously. Or why not a database protocol which can create a separate control stream and then use several streams to receive the output from the different queries simultaneously.

• 引发。4 数据包发起连接，其中数据包 3 和 4 可用于发送数据。默认情况下会实现相当于 syncookie 的功能，以避免 DoS 攻击。INIT 冲突解决以避免多个同时发生的 SCTP 连接。

• Initiation. 4 packet initiation of connections where packet 3 and 4 can be used to send data. The equivalent of syncookies is implemented by default to avoid DoS attacks. INIT collision resolution to avoid several simultaneous SCTP connections.

这个清单还可以更长，但我不会。大多数信息都是从RFC 3286 - 流控制传输协议简介 文档中收集的，因此请阅读该文档以获取更多信息。

This list could be made even longer, but I will not. Most of this information is gathered from the RFC 3286 - An Introduction to the Stream Control Transmission Protocol document, so read on there for more information.

在 SCTP 中，我们谈论的是块，而不是数据包或窗口。由于该协议是面向消息的，因此 SCTP 帧可以包含多个不同的块。块可以是控制块或数据块。控制块用于控制会话，数据块用于发送实际数据。 In SCTP we talk about chunks, not packets or windows anymore. An SCTP frame can contain several different chunks since the protocol is message oriented. A chunk can either be a control or a data chunk. Control chunks is used to control the session, and data chunks are used to send actual data.

SCTP 标头

SCTP Headers

这将是对 SCTP 标头的非常简短的介绍。SCTP 有许多不同类型的数据包，因此我将尝试尽可能遵循 RFC 以及它们如何描述不同的标头，首先对适用于所有 SCTP 数据包的标头进行一般概述。

This will be a very brief introduction to the SCTP headers. SCTP has a lot of different types of packets, and hence I will try to follow the RFC's as close as possible and how they depict the different headers, starting with a general overview of the headers applicable to all SCTP packets.

---

SCTP 通用和通用标头

SCTP Common and generic headers

每个 SCTP 数据包都包含通用标头，如上所示。标头包含四个不同的字段，并为每个 SCTP 数据包设置。

Every SCTP packet contains the Common header as seen above. The header contains four different fields and is set for every SCTP packet.

源端口 - 位 0-15。该字段给出数据包的源端口，即从哪个端口发送的。与 TCP 和 UDP 源端口相同。

Source port - bit 0-15. This field gives the source port of the packet, which port it was sent from. The same as for TCP and UDP source port.

目标端口 - 位 16-31。这是数据包的目标端口，即数据包要去的端口。它与 TCP 和 UDP 目标端口相同。

Destination port - bit 16-31. This is the destination port of the packet, ie., the port that the packet is going to. It is the same as for the TCP and UDP destination port.

验证标签 - 位 32-63。验证标签用于验证数据包来自正确的发送者。它始终设置为与关联初始化期间发起标记中的其他对等方收到的值相同的值，但有一些例外：

Verification Tag - bit 32-63. The verification tag is used to verify that the packet comes from the correct sender. It is always set to the same value as the value received by the other peer in the Initiate Tag during the association initialization, with a few exceptions:

• 包含 INIT 块的 SCTP 数据包必须将验证标记设置为 0。

• An SCTP packet containing an INIT chunk must have the Verification tag set to 0.

• 设置了 T 位的 SHUTDOWN COMPLETE 块必须具有从 SHUTDOWN-ACK 块的验证标记复制的验证标记。

• A SHUTDOWN COMPLETE chunk with the T-bit set must have the verification tag copied from the verification tag of the SHUTDOWN-ACK chunk.

• 包含 ABORT 块的数据包可以将验证标签设置为与导致 ABORT 的数据包相同的验证标签。

• Packets containing ABORT chunk may have the verification tag set to the same verification tag as the packet causing the ABORT.

校验和 - 位 64-95。基于Adler-32算法对整个SCTP数据包计算的校验和。有关此算法的更多信息， 请阅读RFC 2960 - 流控制传输协议，附录 B。

Checksum - bit 64-95. A checksum calculated for the whole SCTP packet based on the Adler-32 algorithm. Read RFC 2960 - Stream Control Transmission Protocol, appendix B for more information about this algorithm.

所有 SCTP 块都遵循特殊的布局，如上所示。这不是一个实际的标题，而是它们外观的形式化方式。

All SCTP chunks has a special layout that they all adhere to as can be seen above. This isn't an actual header, but rather a formalized way of how they do look.

类型 - 位 0-7。该字段指定数据包的块类型，例如它是 INIT 还是 SHUTDOWN 块还是什么？每个块类型都有一个特定的编号，并在下图中指定。以下是块类型的完整列表：

Type - bit 0-7. This field specifies the chunk type of the packet, for example is it an INIT or SHUTDOWN chunk or what? Each chunk type has a specific number, and is specified in the image below. Here is a complete list of Chunk types:

表 2-1。SCTP 类型

Table 2-1. SCTP Types

块数	块名称
0	有效负载数据（DATA）
1	启动（INIT）
2	启动确认（INIT ACK）
3	选择性确认 (SACK)
4	心跳请求（HEARTBEAT）
5	心跳确认（HEARTBEAT ACK）
6	中止（中止）
7	关机（SHUTDOWN）
8	关机确认（SHUTDOWN ACK）
9	操作错误（ERROR）
10	状态 Cookie (COOKIE ECHO)
11	Cookie 确认（COOKIE A​​CK）
12	保留用于显式拥塞通知回显 (ECNE)
13	保留用于减少拥塞窗口 (CWR)
14	关机完成（SHUTDOWN COMPLETE）
15-62	为 IETF 保留
63	IETF 定义的块扩展
64-126	保留给 IETF
127	IETF 定义的块扩展
128-190	保留给 IETF
191	IETF 定义的块扩展
192-254	保留给 IETF
255	IETF 定义的块扩展

块标志 - 位 8-15。块标志通常不被使用，但如果没有其他情况，则设置为将来使用。它们是其他对等点可能需要的块特定标志或信息位。根据规范，此时标志仅在 DATA、ABORT 和 SHUTDOWN COMPLETE 数据包中使用。然而，这可能会改变。

Chunk Flags - bit 8-15. The chunk flags are generally not used but are set up for future usage if nothing else. They are chunk specific flags or bits of information that might be needed for the other peer. According to specifications, flags are only used in DATA, ABORT and SHUTDOWN COMPLETE packets at this moment. This may change however.

很多时候，当您阅读 RFC 时，您可能会遇到一些已被证实的老问题。RFC 2960 - 流控制传输协议文档就是其中一个示例，其中特别指定块标志应始终设置为 0 并被忽略，除非用于某些用途。到处都是这样写的，这会为将来带来问题。如果您进行防火墙或路由，请非常小心，因为此类字段的规范将来可能会发生变化，从而在没有任何合法原因的情况下破坏您的防火墙。例如，以前在 IP 标头中实施 ECN 时就发生过这种情况。更多内容请参见本章的 IP 标头部分。 A lot of times when you read an RFC, you might run into some old proven problems. The RFC 2960 - Stream Control Transmission Protocol document is one example of this, where they specifically specify that the Chunk flags should always be set to 0 and ignored unless used for something. This is written all over the place, and it begs for problems in the future. If you do firewalling or routing, watch out very carefully for this, since specifications for fields like this may change in the future and hence break at your firewall without any legit reason. This happened before with the implementation of ECN in the IP headers for example. See more in the IP headers section of this chapter.

块长度 - 位 16-31。这是以字节计算的块长度。它包括所有标头，包括块类型、块标志、块长度和块值。如果没有 chunk 值，则 chunk 长度将设置为 4（字节）。

Chunk Length - bit 16-31. This is the chunk length calculated in bytes. It includes all headers, including the chunk type, chunk flags, chunk length and chunk value. If there is no chunk value, the chunk length will be set to 4 (bytes).

块值 - 位 32-n。这是特定于每个块的，并且可能包含更多与块类型相关的标志和数据。有时它可能为空，在这种情况下块长度将设置为 4。

Chunk Value - bit 32-n. This is specific to each chunk and may contain more flags and data pertaining to the chunk type. Sometimes it might be empty, in which case the chunk length will be set to 4.

TCP/IP 目的地驱动路由

TCP/IP destination driven routing

当涉及到路由部分时，TCP/IP 的复杂性已经大大增加。一开始，大多数人认为目的地驱动的路由就足够了。然而，在过去的几年里，这变得越来越复杂。如今，Linux 基本上可以在 IP 标头中的每个字段或位上进行路由，甚至还可以基于 TCP、UDP 或 ICMP 标头进行路由。这称为基于策略的路由或高级路由。

TCP/IP has grown in complexity quite a lot when it comes to the routing part. In the beginning, most people thought it would be enough with destination driven routing. The last few years, this has become more and more complex however. Today, Linux can route on basically every single field or bit in the IP header, and even based on TCP, UDP or ICMP headers as well. This is called policy based routing, or advanced routing.

这只是关于如何执行目的地驱动路由的简要讨论。当我们从发送主机发送数据包时，就会创建该数据包。此后，计算机查看数据包目标地址并将其与现有的路由表进行比较。如果目标地址是本地地址，则数据包将通过其硬件 MAC 地址直接发送到该地址。如果数据包位于网关的另一侧，则数据包将发送到网关的 MAC 地址。然后网关将查看 IP 标头并查看数据包的目标地址。再次在路由表中查找目的地址，并将数据包发送到下一个网关等等，直到数据包最终到达目的地的本地网络。

This is simply a brief discussion on how the destination driven routing is performed. When we send a packet from a sending host, the packet is created. After this, the computer looks at the packet destination address and compares it to the routing table that it has. If the destination address is local, the packet is sent directly to that address via its hardware MAC address. If the packet is on the other side of a gateway, the packet is sent to the MAC address of the gateway. The gateway will then look at the IP headers and see the destination address of the packet. The destination address is looked up in the routing table again, and the packet is sent to the next gateway, et cetera, until the packet finally reaches the local network of the destination.

如您所见，此路由非常基本且简单。使用高级路由和基于策略的路由，这会变得更加复杂。我们可以根据数据包的源地址或 TOS 值等对数据包进行不同的路由。

As you can see, this routing is very basic and simple. With the advanced routing and policy based routing, this gets quite a bit more complex. We can route packets differently based on their source address for example, or their TOS value, et cetera.

下一步是什么？

What's next?

本章为您提供了最新信息，以便您充分理解后续章节。已彻底检查了以下内容：

This chapter has brought you up to date to fully understand the subsequent chapters. The following has been gone through thoroughly:

• TCP/IP结构

• TCP/IP structure

• IP 协议功能和标头。

• IP protocol functionality and headers.

• TCP 协议功能和标头。

• TCP protocol functionality and headers.

• UDP 协议功能和标头。

• UDP protocol functionality and headers.

• ICMP 协议功能和标头。

• ICMP protocol functionality and headers.

• TCP/IP 目标驱动路由。

• TCP/IP destination driven routing.

当您稍后开始使用实际的防火墙规则集时，所有这些都会非常方便。所有这些信息都是组合在一起的，将导致更好的防火墙设计。

All of this will come in very handy later on when you start to work with the actual firewall rulesets. All of this information are pieces that fit together, and will lead to a better firewall design.

什么是IP过滤器

What is an IP filter

充分了解 IP 过滤器是什么非常重要。iptables 是一个 IP 过滤器，如果你不完全理解这一点，你将来在设计防火墙时将会遇到严重的问题。

It is important to fully understand what an IP filter is. Iptables is an IP filter, and if you don't fully understand this, you will get serious problems when designing your firewalls in the future.

IP 过滤器主要在 TCP/IP 参考堆栈的第 2 层中运行。然而，Iptables 也能够在第 3 层中工作，这实际上是当今大多数 IP 过滤器所具备的。但根据定义，IP 过滤器在第二层工作。

An IP filter operates mainly in layer 2, of the TCP/IP reference stack. Iptables however has the ability to also work in layer 3, which actually most IP filters of today have. But per definition an IP filter works in the second layer.

如果 IP 过滤器实现严格遵循定义，换句话说，它只能根据 IP 标头（源和目标地址、TOS/DSCP/ECN、TTL、协议等）过滤数据包。 IP 标头。）但是，由于 Iptables 实现并不完全严格地围绕此定义，因此它还能够根据数据包较深层（TCP、UDP 等）和较浅层（MAC 源地址）的其他标头来过滤数据包）。

If the IP filter implementation is strictly following the definition, it would in other words only be able to filter packets based on their IP headers (Source and Destionation address, TOS/DSCP/ECN, TTL, Protocol, etc. Things that are actually in the IP header.) However, since the Iptables implementation is not perfectly strict around this definition, it is also able to filter packets based on other headers that lie deeper into the packet (TCP, UDP, etc), and shallower (MAC source address).

然而有一件事，现在 iptables 的要求相当严格。它不会“跟随”流或将数据拼凑在一起。这太消耗处理器和内存了。稍后将进一步讨论其含义。它确实跟踪数据包并查看它们是否属于同一流（通过序列号、端口号等），几乎与真正的 TCP/IP 堆栈完全相同。这称为连接跟踪，因此我们可以执行诸如目标和源网络地址转换（通常称为 DNAT 和 SNAT）以及数据包状态匹配之类的操作。

There is one thing however, that iptables is rather strict about these days. It does not "follow" streams or puzzle data together. This would simply be too processor- and memoryconsuming . The implications of this will be discussed a little bit more further on. It does keep track of packets and see if they are of the same stream (via sequence numbers, port numbers, etc.) almost exactly the same way as the real TCP/IP stack. This is called connection tracking, and thanks to this we can do things such as Destination and Source Network Address Translation (generally called DNAT and SNAT), as well as state matching of packets.

正如我上面所暗示的，iptables 无法将来自不同数据包的数据相互连接（默认情况下），因此您永远无法完全确定您将始终看到完整的数据。我特别提到这一点是因为在不同的邮件列表上不断地至少有几个与 netfilter 和 iptables 相关的问题，以及如何做通常被认为是一个非常糟糕的主意的事情。例如，每次出现基于 Windows 的新病毒时，都会有几个不同的人询问如何删除包含特定字符串的所有流。这样做的坏主意是它很容易被规避。例如，如果我们匹配这样的内容：

As I implied above, iptables can not connect data from different packets to each other (per default), and hence you can never be fully certain that you will see the complete data at all times. I am specifically mentioning this since there are constantly at least a couple of questions about this on the different mailing lists pertaining to netfilter and iptables and how to do things that are generally considered a really bad idea. For example, every time there is a new windows based virus, there are a couple of different persons asking how to drop all streams containing a specific string. The bad idea about this is that it is so easily circumvented. For example if we match for something like this:

执行程序

cmd.exe

现在，如果病毒/漏洞编写者足够聪明，可以将数据包大小设置得非常小，以致 cmd 出现在一个数据包中，而 .exe 出现在下一个数据包中，会发生什么情况？或者，如果数据包必须通过本身具有如此小的数据包大小的网络，该怎么办？是的，由于这些字符串匹配函数无法跨数据包边界工作，因此数据包无论如何都会通过。

Now, what happens if the virus/exploit writer is smart enough to make the packet size so small that cmd winds up in one packet, and .exe winds up in the next packet? Or what if the packet has to travel through a network that has this small a packet size on its own? Yes, since these string matching functions is unable to work across packet boundaries, the packet will get through anyway.

你们中的一些人现在可能会问自己，为什么我们不简单地使字符串匹配等能够跨数据包边界读取？实际上相当简单。这对处理器时间来说成本太高。连接跟踪已经占用了大量处理器时间，令人完全放心。为连接跟踪添加另一层额外的复杂性（例如这样的）可能会导致比我们任何人预期的更多的防火墙消失。不要考虑每台机器上这个简单的任务将使用多少内存。

Some of you may now be asking yourself, why don't we simply make it possible for the string matches, etcetera to read across packet boundaries? It is actually fairly simple. It would be too costly on processor time. Connection tracking is already taking way to much processor time to be totally comforting. To add another extra layer of complexity to connection tracking, such as this, would probably kill more firewalls than anyone of us could expect. Not to think of how much memory would be used for this simple task on each machine.

未开发此功能还有第二个原因。有一种技术叫做代理。代理是为了处理较高层的流量而开发的，因此可以更好地满足这些要求。代理最初是为了处理下载和经常使用的页面而开发的，并帮助您充分利用缓慢的互联网连接。例如，鱿鱼是一个网络代理。想要下载页面的人发送请求，代理要么抓取请求，要么接收请求并打开与网络浏览器的连接，然后连接到网络服务器并下载文件，当它下载完文件或页面，它将其发送给客户端。现在，如果第二个浏览器想要再次读取同一页面，文件或页面已经下载到代理，可以直接发送，并为我们节省带宽。

There is also a second reason for this functionality not being developed. There is a technology called proxies. Proxies were developed to handle traffic in the higher layers, and are hence much better at fullfilling these requirements. Proxies were originally developed to handle downloads and often used pages and to help you get the most out of slow Internet connections. For example, Squid is a webproxy. A person who wants to download a page sends the request, the proxy either grabs the request or receives the request and opens the connection to the web browser, and then connects to the webserver and downloads the file, and when it has downloaded the file or page, it sends it to the client. Now, if a second browser wants to read the same page again, the file or page is already downloaded to the proxy, and can be sent directly, and saves bandwidth for us.

正如您可能了解的那样，代理还具有很多功能可以查看其下载的文件的实际内容。正因为如此，他们更擅长查看整个流、文件、页面等的内部。

As you may understand, proxies also have quite a lot of functionality to go in and look at the actual content of the files that it downloads. Because of this, they are much better at looking inside the whole streams, files, pages etc.

现在，在警告您在 iptables 和 netfilter 中进行 7 级过滤的固有问题之后，实际上有一组补丁可以解决这些问题。这称为http://l7-filter.sourceforge.net/。它可以用来匹配很多第7层协议，但主要是与QoS和流量计费一起使用，尽管它也可以用于纯粹的过滤。l7-filter 仍然是实验性的，并且是在内核和 netfilter 核心团队之外开发的，因此您不会在这里听到更多关于它的信息。

Now, after warning you about the inherent problems of doing level 7 filtering in iptables and netfilter, there is actually a set of patches that has attacked these problems. This is called http://l7-filter.sourceforge.net/. It can be used to match on a lot of layer 7 protocols but is mainly to be used together with QoS and traffic accounting, even though it can be used for pure filtering as well. The l7-filter is still experimental and developed outside the kernel and netfilter coreteam, and hence you will not hear more about it here.

IP 过滤术语和表达

IP filtering terms and expressions

为了充分理解接下来的章节，必须理解一些通用术语和表达方式，包括有关 TCP/IP 章节的大量细节。这是 IP 过滤中最常用术语的列表。

To fully understand the upcoming chapters there are a few general terms and expressions that one must understand, including a lot of details regarding the TCP/IP chapter. This is a listing of the most common terms used in IP filtering.

• 丢弃/拒绝 - 当数据包被丢弃或拒绝时，它只是被删除，并且不会采取进一步的操作。没有回复告诉主机它已被丢弃，也没有以任何方式通知数据包的接收主机。数据包就这样消失了。

• Drop/Deny - When a packet is dropped or denied, it is simply deleted, and no further actions are taken. No reply to tell the host it was dropped, nor is the receiving host of the packet notified in any way. The packet simply disappears.

• 拒绝 - 这与丢弃或拒绝目标或策略基本相同，只是我们还向发送被丢弃数据包的主机发送回复。回复可以是指定的，也可以自动计算为某个值。（到目前为止，不幸的是，还没有 iptables 功能来发送数据包，通知接收主机被拒绝的数据包发生了什么（即，执行拒绝目标的相反操作）。这在某些情况下非常好，因为接收主机主机无法阻止拒绝服务攻击的发生。）

• Reject - This is basically the same as a drop or deny target or policy, except that we also send a reply to the host sending the packet that was dropped. The reply may be specified, or automatically calculated to some value. (To this date, there is unfortunately no iptables functionality to also send a packet notifying the receiving host of the rejected packet what happened (ie, doing the reverse of the Reject target). This would be very good in certain circumstances, since the receiving host has no ability to stop Denial of Service attacks from happening.)

• 状态 - 与整个数据包流相比的数据包的特定状态。例如，如果该数据包是防火墙看到或了解的第一个数据包，则将其视为新数据包（TCP 连接中的 SYN 数据包），或者如果它是防火墙了解的已建立连接的一部分，则将其视为新数据包待成立。通过连接跟踪系统了解状态，该系统跟踪所有会话。

• State - A specific state of a packet in comparison to a whole stream of packets. For example, if the packet is the first that the firewall sees or knows about, it is considered new (the SYN packet in a TCP connection), or if it is part of an already established connection that the firewall knows about, it is considered to be established. States are known through the connection tracking system, which keeps track of all the sessions.

• 链 - 链包含应用于遍历该链的数据包的规则集。每个链都有特定的用途（例如，它连接到哪个表，该表指定该链能够做什么），以及特定的应用程序区域（例如，仅转发的数据包，或仅发往该主机的数据包）。在iptables中，有几种不同的链，将在后面的章节中深入讨论。

• Chain - A chain contains a ruleset of rules that are applied on packets that traverses the chain. Each chain has a specific purpose (e.g., which table it is connected to, which specifies what this chain is able to do), as well as a specific application area (e.g., only forwarded packets, or only packets destined for this host). In iptables, there are several different chains, which will be discussed in depth in later chapters.

• 表 - 每个表都有特定的用途，在 iptables 中有 4 个表。raw、nat、mangle 和过滤表。例如，filter表专门用于过滤数据包，而nat表专门用于NAT（网络地址转换）数据包。

• Table - Each table has a specific purpose, and in iptables there are 4 tables. The raw, nat, mangle and filter tables. For example, the filter table is specifically designed to filter packets, while the nat table is specifically designed to NAT (Network Address Translation) packets.

• 匹配 - 当涉及到 IP 过滤时，这个词可以有两种不同的含义。第一个含义是单个匹配，它告诉规则该标头必须包含此信息。例如，--source 匹配告诉我们源地址必须是特定的网络范围或主机地址。第二个含义是整个规则是否匹配。如果数据包匹配整个规则，则将执行跳转或目标指令（例如，数据包将被丢弃。）

• Match - This word can have two different meanings when it comes to IP filtering. The first meaning would be a single match that tells a rule that this header must contain this and this information. For example, the --source match tells us that the source address must be a specific network range or host address. The second meaning is if a whole rule is a match. If the packet matches the whole rule, the jump or target instructions will be carried out (e.g., the packet will be dropped.)

• 目标 - 通常为规则集中的每个规则设置一个目标。如果规则完全匹配，目标规范会告诉我们如何处理数据包。例如，我们是否应该删除或接受它，或者对其进行 NAT 等。还有一种称为跳转规范的内容，有关详细信息，请参阅此列表中的跳转说明。最后一点，每个规则可能没有目标或跳转，但也可能有。

• Target - There is generally a target set for each rule in a ruleset. If the rule has matched fully, the target specification tells us what to do with the packet. For example, if we should drop or accept it, or NAT it, etc. There is also something called a jump specification, for more information see the jump description in this list. As a last note, there might not be a target or jump for each rule, but there may be.

• 规则 - 在大多数 IP 过滤器实现（包括 iptables 实现）中，规则是一组匹配或多个匹配以及单个目标。有一些实现允许您对每个规则使用多个目标/操作。

• Rule - A rule is a set of a match or several matches together with a single target in most implementations of IP filters, including the iptables implementation. There are some implementations which let you use several targets/actions per rule.

• 规则集 - 规则集是放入整个 IP 过滤器实现中的完整规则集。对于 iptables，这包括过滤器、nat、raw 和 mangle 表以及所有后续链中设置的所有规则。大多数时候，它们被写在某种配置文件中。

• Ruleset - A ruleset is the complete set of rules that are put into a whole IP filter implementation. In the case of iptables, this includes all of the rules set in the filter, nat, raw and mangle tables, and in all of the subsequent chains. Most of the time, they are written down in a configuration file of some sort.

• 跳转 - 跳转指令与目标密切相关。跳转指令的编写方式与 iptables 中的目标完全相同，不同之处在于您不编写目标名称，而是编写另一个链的名称。如果规则匹配，则数据包将被发送到第二条链并在该链中照常进行处理。

• Jump - The jump instruction is closely related to a target. A jump instruction is written exactly the same as a target in iptables, with the exception that instead of writing a target name, you write the name of another chain. If the rule matches, the packet will hence be sent to this second chain and be processed as usual in that chain.

• 连接跟踪 - 实现连接跟踪的防火墙能够简单地跟踪连接/流。这样做的能力通常是在大量处理器和内存使用的影响下完成的。不幸的是，这在 iptables 中也是如此，但是我们已经做了很多工作来解决这个问题。然而，好的一面是，通过防火墙策略的实施者正确使用连接跟踪，防火墙将更加安全。

• Connection tracking - A firewall which implements connection tracking is able to track connections/streams simply put. The ability to do so is often done at the impact of lots of processor and memory usage. This is unfortunately true in iptables as well, but much work has been done to work on this. However, the good side is that the firewall will be much more secure with connection tracking properly used by the implementer of the firewall policies.

• 接受 - 接受数据包并让其通过防火墙规则。这与丢弃或拒绝目标以及拒绝目标相反。

• Accept - To accept a packet and to let it through the firewall rules. This is the opposite of the drop or deny targets, as well as the reject target.

• 策略 - 在实施防火墙时，我们大多数时候都会谈论两种策略。首先，我们有链策略，它告诉防火墙实现在没有与数据包匹配的规则的情况下对数据包采取的默认行为。这是我们将在本书中使用的该词的主要用法。第二种类型的策略是我们可能已编写文档的安全策略，例如针对整个公司或针对此特定网段的安全策略。安全策略是非常好的文档，需要在开始实际实施防火墙之前仔细考虑并正确研究。

• Policy - There are two kinds of policies that we speak about most of the time when implementing a firewall. First we have the chain policies, which tells the firewall implementation the default behaviour to take on a packet if there was no rule that matched it. This is the main usage of the word that we will use in this book. The second type of policy is the security policy that we may have written documentation on, for example for the whole company or for this specific network segment. Security policies are very good documents to have thought through properly and to study properly before starting to actually implement the firewall.

如何规划 IP 过滤器

How to plan an IP filter

规划防火墙时首先要考虑的步骤之一是它们的位置。这应该是一个相当简单的步骤，因为无论如何，大多数网络都应该被很好地分段。首先想到的地方之一是本地网络和互联网之间的网关。这是一个安全应该相当严密的地方。此外，在较大的网络中，通过防火墙将不同的部门彼此分开可能是一个好主意。例如，为什么开发团队应该访问人力资源网络，或者为什么不保护经济部门免受其他网络的影响？简而言之，您不希望愤怒的员工拿着解雇通知书篡改薪资数据库。

One of the first steps to think about when planning the firewall is their placement. This should be a fairly simple step since mostly your networks should be fairly well segmented anyway. One of the first places that comes to mind is the gateway between your local network(s) and the Internet. This is a place where there should be fairly tight security. Also, in larger networks it may be a good idea to separate different divisions from each other via firewalls. For example, why should the development team have access to the human resources network, or why not protect the economic department from other networks? Simply put, you don't want an angry employee with the pink slip tampering with the salary databases.

简而言之，上述意味着您应该尽可能地规划您的网络，并将它们规划为隔离的。特别是如果网络是中型到大型（100 个工作站或更多，基于网络的不同方面）。在这些较小的网络之间，尝试放置仅允许您想要的流量类型的防火墙。

Simply put, the above means that you should plan your networks as well as possible, and plan them to be segregated. Especially if the network is medium- to big-sized (100 workstations or more, based on different aspects of the network). In between these smaller networks, try to put firewalls that will only allow the kind of traffic that you would like.

如果您有可以从 Internet 访问的服务器，那么在您的网络中创建非军事区 (DMZ) 也是一个好主意。DMZ 是一个带有服务器的小型物理网络，它是极端封闭的。这降低了任何人实际进入 DMZ 中的计算机的风险，并且降低了任何人实际进入并从外部下载任何木马等的风险。之所以被称为非军事区，是因为它们必须从内部和外部都可以到达，因此它们是一种灰色区域（简称DMZ）。

It may also be a good idea to create a De-Militarized Zone (DMZ) in your network in case you have servers that are reached from the Internet. A DMZ is a small physical network with servers, which is closed down to the extreme. This lessens the risk of anyone actually getting in to the machines in the DMZ, and it lessens the risk of anyone actually getting in and downloading any trojans etc. from the outside. The reason that they are called de-militarized zones is that they must be reachable from both the inside and the outside, and hence they are a kind of grey zone (DMZ simply put).

有多种方法可以在防火墙中设置策略和默认行为，本节将讨论您在实际开始实施防火墙之前应该考虑的实际理论，并帮助您充分考虑您的决定程度。

There are a couple of ways to set up the policies and default behaviours in a firewall, and this section will discuss the actual theory that you should think about before actually starting to implement your firewall, and helping you to think through your decisions to the fullest extent.

在我们开始之前，您应该了解大多数防火墙都有默认行为。例如，如果特定链中没有规则匹配，则可以默认删除或接受该规则。不幸的是，每个链只有一个策略，但如果我们希望每个网络接口等有不同的策略，这通常很容易解决。

Before we start, you should understand that most firewalls have default behaviours. For example, if no rule in a specific chain matches, it can be either dropped or accepted per default. Unfortunately, there is only one policy per chain, but this is often easy to get around if we want to have different policies per network interface etc.

我们通常使用两种基本策略。要么我们放弃除我们指定的内容之外的所有内容，要么我们接受除我们明确删除的内容之外的所有内容。大多数时候，我们最感兴趣的是放弃政策，然后接受我们想要特别允许的一切。这意味着默认情况下防火墙更加安全，但这也可能意味着您需要做更多的工作才能让防火墙正常运行。

There are two basic policies that we normally use. Either we drop everything except that which we specify, or we accept everything except that which we specifically drop. Most of the time, we are mostly interested in the drop policy, and then accepting everything that we want to allow specifically. This means that the firewall is more secure per default, but it may also mean that you will have much more work in front of you to simply get the firewall to operate properly.

您要做的第一个决定就是简单地弄清楚您应该使用哪种类型的防火墙。安全问题有多大？什么样的应用程序必须能够通过防火墙？某些应用程序对防火墙来说是可怕的，原因很简单，它们会协商用于控制会话内数据流的端口。这使得防火墙很难知道要打开哪些端口。最常见的应用程序可与 iptables 配合使用，但不幸的是，更罕见的应用程序至今仍无法使用。

Your first decision to make is to simply figure out which type of firewall you should use. How big are the security concerns? What kind of applications must be able to get through the firewall? Certain applications are horrible to firewalls for the simple reason that they negotiate ports to use for data streams inside a control session. This makes it extremely hard for the firewall to know which ports to open up. The most common applications works with iptables, but the more rare ones do not work to this day, unfortunately.

还有一些应用程序只能部分运行，例如 ICQ。正常的 ICQ 使用效果很好，但聊天或文件发送功能则不行，因为它们需要特定的代码来处理协议。由于 ICQ 协议不是标准化的（它们是专有的并且可能随时更改），因此大多数 IP 过滤器都选择将 ICQ 协议处理程序排除在外，或者作为可应用于防火墙的补丁。Iptables 选择将它们保留为单独的补丁。 There are also some applications that work partially, such as ICQ. Normal ICQ usage works perfectly, but not the chat or file sending functions, since they require specific code to handle the protocol. Since the ICQ protocols are not standardized (they are proprietary and may be changed at any time) most IP filters have chosen to either keep the ICQ protocol handlers out, or as patches that can be applied to the firewalls. Iptables have chosen to keep them as separate patches.

应用分层安全措施也可能是一个好主意，到目前为止我们实际上已经部分讨论过。我们的意思是，您应该同时使用尽可能多的安全措施，并且不要依赖任何一种单一的安全概念。将此作为安全性的基本概念将至少将安全性提高十倍。举个例子，让我们看一下这个。

It may also be a good idea to apply layered security measures, which we have actually already discussed partially so far. What we mean with this, is that you should use as many security measures as possible at the same time, and don't rely on any one single security concept. Having this as a basic concept for your security will increase security tenfold at least. For an example, let's look at this.

正如您所看到的，在本示例中，我选择将 Cisco PIX 防火墙放置在所有三个网络连接的外围。如果需要，它可以对内部 LAN 以及 DMZ 进行 NAT。它还可能阻止除 http 返回流量以及 ftp 和 ssh 流量之外的所有传出流量。它可以允许来自 LAN 和 Internet 的传入 http 流量，以及来自 LAN 的 ftp 和 ssh 流量。除此之外，我们注意到每个网络服务器都基于 Linux，因此也可以在每台机器上添加 iptables 和 netfilter，并在这些机器上添加相同的基本策略。这样，如果有人设法破坏了 Cisco PIX，我们仍然可以在每台计算机上本地依赖 netfilter 防火墙，反之亦然。这允许所谓的分层安全性。

As you can see, in this example I have in this example chosen to place a Cisco PIX firewall at the perimeter of all three network connections. It may NAT the internal LAN, as well as the DMZ if necessary. It may also block all outgoing traffic except http return traffic as well as ftp and ssh traffic. It can allow incoming http traffic from both the LAN and the Internet, and ftp and ssh traffic from the LAN. On top of this, we note that each webserver is based on Linux, and can hence throw iptables and netfilter on each of the machines as well and add the same basic policies on these. This way, if someone manages to break the Cisco PIX, we can still rely on the netfilter firewalls locally on each machine, and vice versa. This allows for so called layered security.

除此之外，我们可以 在每台机器上添加Snort 。Snort 是一个优秀的开源网络入侵检测系统（NIDS），它在它看到的数据包中查找签名，如果它看到某种攻击或入侵的签名，它可以向管理员发送电子邮件并通知他，甚至对攻击做出主动响应，例如封锁攻击来源的IP。应该注意的是，不应轻易使用主动响应，因为 snort 具有报告大量误报的不良行为（例如，报告实际上不是攻击的攻击）。

On top of this, we may add Snort on each of the machines. Snort is an excellent open source network intrusion detection system (NIDS) which looks for signatures in the packets that it sees, and if it sees a signature of some kind of attack or breakin it can either e-mail the administrator and notify him about it, or even make active responses to the attack such as blocking the IP from which the attack originated. It should be noted that active responses should not be used lightly since snort has a bad behaviour of reporting lots of false positives (e.g., reporting an attack which is not really an attack).

在网络服务器前面添加一个代理来捕获一些坏数据包也可能是一个好主意，这也可能是为所有本地生成的网络连接添加的可能性。通过网络代理，您可以缩小员工网络流量使用的范围，并在一定程度上限制他们的网络使用。至于您自己的网络服务器的网络代理，您可以使用它来阻止一些最明显的连接通过。可能值得使用的一个好的代理是Squid。

It could also be a good idea to throw in an proxy in front of the webservers to catch some of the bad packets as well, which could also be a possibility to throw in for all of the locally generated webconnections. With a webproxy you can narrow down on traffic used by webtraffic from your employees, as well as restrict their webusage to some extent. As for a webproxy to your own webservers, you can use it to block some of the most obvious connections to get through. A good proxy that may be worth using is the Squid.

另一种可以采取的预防措施是安装Tripwire。这是一种优秀的最后一道防线应用程序，它通常被认为是主机入侵检测系统。它的作用是对配置文件中指定的所有文件进行校验，然后偶尔从 cron 运行一次，以查看所有指定的文件是否与以前相同，或者没有以非法方式更改。换句话说，该程序将能够查明是否有人真正能够侵入并篡改系统。建议在所有网络服务器上运行它。

Another precaution that one can take is to install Tripwire. This is an excellent last line of defense kind of application, it is generally considered to be a Host Intrusion Detection System. What it does is to make checksums of all the files specified in a configuration file, and then it is run from cron once in a while to see that all of the specified files are the same as before, or have not changed in an illegit way. This program will in other words be able to find out if anyone has actually been able to get through and tampered with the system. A suggestion is to run this on all of the webservers.

最后要注意的一点是，正如我们所知，遵循标准总是一件好事。正如您已经在 ICQ 示例中看到的那样，如果您不使用标准化系统，事情可能会出现严重错误。对于您自己的环境，这在某种程度上可以忽略，但如果您正在运行宽带服务或调制解调器池，它就变得更加重要。通过您进行联系的人必须始终能够依赖您的标准化，并且您不能期望每个人都运行您选择的特定操作系统。有些人想运行 Windows，有些人想运行 Linux 甚至 VMS 等等。如果您将安全性建立在专有系统上，那么您就会遇到麻烦。

One last thing to note is that it is always a good thing to follow standards, as we know. As you have already seen with the ICQ example, if you don't use standardized systems, things can go terribly wrong. For your own environments, this can be ignored to some extent, but if you are running a broadband service or modempool, it gets all the more important. People who connect through you must always be able to rely on your standardization, and you can't expect everyone to run the specific operating system of your choice. Some people want to run Windows, some want to run Linux or even VMS and so on. If you base your security on proprietary systems, you are in for some trouble.

瑞典出现的某些宽带服务就是一个很好的例子，这些服务的很多安全性都基于微软网络登录。一开始这听起来像是一个好主意，但是一旦我们开始考虑其他操作系统等，这就不再是一个好主意了。运行 Linux 的人如何上网？还是VAX/VMS？还是HP/UX？对于 Linux，当然可以做到这一点，如果不是因为网络管理员通过简单地阻止运行 Linux 的任何人来拒绝他们使用宽带服务。然而，这本书并不是关于什么是最好的神学讨论，所以让我们把它作为一个例子来说明为什么使用非标准是一个坏主意。

A good example of this is certain broadband services that have popped up in Sweden who base lots of security on Microsoft network logon. This may sound like a great idea to begin with, but once we start considering other operating systems and so on, this is no longer such a good idea. How will someone running Linux get online? Or VAX/VMS? Or HP/UX? With Linux it can be done of course, if it wasn't for the fact that the network administrator refuses anyone to use the broadband service if they are running linux by simply blocking them in such case. However, this book is not a theological discussion of what is best, so let's leave it as an example of why it is a bad idea to use non-standards.

下一步是什么？

What's next?

本章介绍了一些可以用来保护网络、工作站和服务器的基本 IP 过滤和安全措施。提出了以下主题：

This chapter has gone through several of the basic IP filtering and security measures that you can take to secure your networks, workstations and servers. The following subjects have been brought up:

• IP过滤的使用

• IP filtering usage

• IP过滤策略

• IP filtering policies

• 网络规划

• Network planning

• 防火墙规划

• Firewall planning

• 分层安全技术

• Layered security techniques

• 网络分段

• Network segmentation

在下一章中，我们将快速了解什么是网络地址转换 (NAT)，之后我们将开始仔细研究 Iptables 及其功能，并开始实际操作这个野兽。

In the next chapter we will take a quick look at what Network Address Translation (NAT) is, and after that we will start looking closer at Iptables and it's functionality and actually start getting hands on with the beast.

NAT 的用途以及基本术语和表达

What NAT is used for and basic terms and expressions

基本上，NAT 允许一台主机或多台主机以某种方式共享相同的 IP 地址。例如，假设我们有一个由 5-10 个客户端组成的本地网络。我们将它们的默认网关设置为通过 NAT 服务器。通常情况下，数据包只会由网关机器转发，但在 NAT 服务器的情况下，情况略有不同。

Basically, NAT allows a host or several hosts to share the same IP address in a way. For example, let's say we have a local network consisting of 5-10 clients. We set their default gateways to point through the NAT server. Normally the packet would simply be forwarded by the gateway machine, but in the case of an NAT server it is a little bit different.

正如我们已经说过的，NAT 服务器将数据包的源地址和目标地址转换为不同的地址。NAT 服务器接收数据包，重写源和/或目标地址，然后重新计算数据包的校验和。NAT 最常见的用法之一是 SNAT（源网络地址转换）功能。基本上，如果我们无力承担或看不到为每个客户端拥有真正的公共 IP 的任何真正想法，则在上面的示例中使用此方法。在这种情况下，我们使用本地网络的私有 IP 范围之一（例如 192.168.1.0/24），然后为本地网络打开 SNAT。然后，SNAT 会将所有 192.168.1.0 地址转换为它自己的公共 IP（例如 217.115.95.34）。这样，就会有 5-10 个或更多的客户端使用相同的共享 IP 地址。

NAT servers translates the source and destination addresses of packets as we already said to different addresses. The NAT server receives the packet, rewrites the source and/or destination address and then recalculates the checksum of the packet. One of the most common usages of NAT is the SNAT (Source Network Address Translation) function. Basically, this is used in the above example if we can't afford or see any real idea in having a real public IP for each and every one of the clients. In that case, we use one of the private IP ranges for our local network (for example, 192.168.1.0/24), and then we turn on SNAT for our local network. SNAT will then turn all 192.168.1.0 addresses into it's own public IP (for example, 217.115.95.34). This way, there will be 5-10 clients or many many more using the same shared IP address.

还有一种叫做 DNAT 的东西，在设置服务器等方面非常有帮助。首先，在节省 IP 空间方面，您可以帮助实现更大的利益，其次，您可以获得或多或少完全无法穿透的信息。以简单的方式在您的服务器和真实服务器之间设置防火墙，或者简单地为分隔成多个物理上不同服务器的多个服务器共享一个 IP。例如，我们可能在同一台计算机上运行一个包含 Web 服务器和 ftp 服务器的小型公司服务器场，而有一个物理上独立的计算机，其中包含几个不同的聊天服务，在家或在路上工作的员工可以使用这些服务来保持联系。与现场员工保持联系。然后，我们可以通过 DNAT 从外部在同一 IP 上运行所有这些服务。

There is also something called DNAT, which can be extremely helpful when it comes to setting up servers etc. First of all, you can help the greater good when it comes to saving IP space, second, you can get an more or less totally impenetrable firewall in between your server and the real server in an easy fashion, or simply share an IP for several servers that are separated into several physically different servers. For example, we may run a small company server farm containing a webserver and ftp server on the same machine, while there is a physically separated machine containing a couple of different chat services that the employees working from home or on the road can use to keep in touch with the employees that are on-site. We may then run all of these services on the same IP from the outside via DNAT.

上面的示例也基于单独的端口 NAT，或通常称为 PNAT。我们在本书中并不经常提到这一点，因为 netfilter 中的 DNAT 和 SNAT 功能已经涵盖了它。

The above example is also based on separate port NAT'ing, or often called PNAT. We don't refer to this very often throughout this book, since it is covered by the DNAT and SNAT functionality in netfilter.

在 Linux 中，实际上可以使用两种不同类型的 NAT，即 Fast-NAT 或 Netfilter-NAT。Fast-NAT是在Linux内核的IP路由代码内部实现的，而Netfilter-NAT也在Linux内核中实现，但在netfilter代码内部。由于本书不会太深入地涉及 IP 路由代码，因此除了一些注释外，我们几乎将其留在这里。Fast-NAT 通常被称为此名称，因为它比 netfilter NAT 代码快得多。它不跟踪连接，这是它的主要优点和缺点。连接跟踪需要大量的处理器能力，因此速度较慢，这是 Fast-NAT 比 Netfilter-NAT 更快的主要原因之一。正如我们也说过的，Fast-NAT 的缺点是不跟踪连接，这意味着它不能很好地对整个网络进行 SNAT，也不能对复杂的协议进行 NAT，例如 FTP、IRC 以及 Netfilter-NAT 能够很好处理的其他协议。这是可能的，但需要做的工作比 Netfilter 实现预期的要多得多。

In Linux, there are actually two separate types of NAT that can be used, either Fast-NAT or Netfilter-NAT. Fast-NAT is implemented inside the IP routing code of the Linux kernel, while Netfilter-NAT is also implemented in the Linux kernel, but inside the netfilter code. Since this book won't touch the IP routing code too closely, we will pretty much leave it here, except for a few notes. Fast-NAT is generally called by this name since it is much faster than the netfilter NAT code. It doesn't keep track of connections, and this is both its main pro and con. Connection tracking takes a lot of processor power, and hence it is slower, which is one of the main reasons that the Fast-NAT is faster than Netfilter-NAT. As we also said, the bad thing about Fast-NAT doesn't track connections, which means it will not be able to do SNAT very well for whole networks, neither will it be able to NAT complex protocols such as FTP, IRC and other protocols that Netfilter-NAT is able to handle very well. It is possible, but it will take much, much more work than would be expected from the Netfilter implementation.

最后还有一个词基本上是 SNAT 的同义词，即 Masquerade 词。在 Netfilter 中，伪装与 SNAT 几乎相同，不同之处在于伪装会自动将新源 IP 设置为传出网络接口的默认 IP 地址。

There is also a final word that is basically a synonym to SNAT, which is the Masquerade word. In Netfilter, masquerade is pretty much the same as SNAT with the exception that masquerading will automatically set the new source IP to the default IP address of the outgoing network interface.

使用 NAT 的注意事项

Caveats using NAT

正如我们已经在某种程度上解释的那样，使用 NAT 有很多小注意事项。主要问题是某些协议和应用程序可能根本无法工作。希望这些应用程序在您管理的网络中不太常见，在这种情况下，它应该不会造成大问题。

As we have already explained to some extent, there are quite a lot of minor caveats with using NAT. The main problem is certain protocols and applications which may not work at all. Hopefully, these applications are not too common in the networks that you administer, and in such case, it should cause no huge problems.

第二个也是较小的问题是应用程序和协议只能部分工作。这些协议比那些根本不起作用的协议更常见，这是非常不幸的，但看起来我们对此无能为力。如果继续构建复杂的协议，我们将不得不继续面对这个问题。尤其是在协议未标准化的情况下。

The second and smaller problem is applications and protocols which will only work partially. These protocols are more common than the ones that will not work at all, which is quite unfortunate, but there isn't very much we can do about it as it seems. If complex protocols continue to be built, this is a problem we will have to continue living with. Especially if the protocols aren't standardized.

在我看来，第三个也是最大的问题是，坐在 NAT 服务器后面访问互联网的用户将无法运行自己的服务器。当然，这是可以做到的，但是需要花费更多的时间和工作来进行设置。在公司中，这可能比拥有由不同员工运行的大量服务器可以通过互联网访问而无需任何监督更受欢迎。然而，对于家庭用户来说，这应该是最后避免的。作为互联网服务提供商，您永远不应该将您的客户从私有 IP 范围转换为公共 IP。它会给你带来比值得处理的更多的麻烦，并且总会有一个或另一个客户希望这个或那个协议完美地工作。如果不这样做，你就会被贬低。

The third, and largest problem, in my point of view, is the fact that the user who sits behind a NAT server to get out on the internet will not be able to run his own server. It could be done, of course, but it takes a lot more time and work to set this up. In companies, this is probably preferred over having tons of servers run by different employees that are reachable from the Internet, without any supervision. However, when it comes to home users, this should be avoided to the very last. You should never as an Internet service provider NAT your customers from a private IP range to a public IP. It will cause you more trouble than it is worth having to deal with, and there will always be one or another client which will want this or that protocol to work flawlessly. When it doesn't, you will be called down upon.

作为关于 NAT 警告的最后一点，应该提到的是 NAT 实际上或多或少只是一种 hack。NAT 是IANA制定的解决方案和其他组织指出，互联网呈指数级增长，IP 地址很快就会出现短缺。NAT 过去和现在都是解决 IPv4 问题的短期解决方案（是的，我们之前讨论过的 IP 是 IPv4 的简短版本，代表互联网协议版本 4）。IPv6 协议是解决 IPv4 地址短缺问题的长期解决方案，它还解决了大量其他问题。IPv6 有 128 位分配给它们的地址，而 IPv4 只有 32 位用于 IP 地址。地址空间的增加令人难以置信。拥有足够的 IP 地址来为地球上的每个原子设置一个 IP 地址似乎很荒谬，但另一方面，也没有人预计 IPv4 地址范围会太小。

As one last note on the caveats of NAT, it should be mentioned that NAT is actually just a hack more or less. NAT was a solution that was worked out while the IANA and other organisations noted that the Internet grew exponentially, and that the IP addresses would soon be in shortage. NAT was and is a short term solution to the problem of the IPv4 (Yes, IP which we have talked about before is a short version of IPv4 which stands for Internet Protocol version 4). The long term solution to the IPv4 address shortage is the IPv6 protocol, which also solves a ton of other problems. IPv6 has 128 bits assigned to their addresses, while IPv4 only have 32 bits used for IP addresses. This is an incredible increase in address space. It may seem like ridiculous to have enough IP addresses to set one IP address for every atom in our planet, but on the other hand, noone expected the IPv4 address range to be too small either.

理论上的 NAT 机器示例

Example NAT machine in theory

这是一个小型的理论场景，我们希望在 2 个不同的网络和 Internet 连接之间有一个 NAT 服务器。我们想要做的是将两个网络相互连接，并且两个网络都应该能够互相访问并访问互联网。我们将讨论您应该考虑的硬件问题，以及在实际开始实施 NAT 机器之前您应该考虑的其他理论。

This is a small theoretical scenario where we want a NAT server between 2 different networks and an Internet connection. What we want to do is to connect 2 networks to each other, and both networks should have access to each other and the Internet. We will discuss the hardware questions you should take into consideration, as well as other theory you should think about before actually starting to implement the NAT machine.

下一步是什么？

What's next?

我们在本章中详细解释了 NAT 及其相关理论。我们特别讨论了几个不同的使用角度，以及将 NAT 与代理一起使用时可能出现的一些常见问题。本章详细介绍了以下领域。

We have in this chapter in detail explained NAT and the theory around it. In special we have discussed a couple of different angles to use, and some of the normal problems that may arise from using NAT together with proxies. This chapter has covered the following areas in detail.

• NAT使用

• NAT usage

• NAT组件

• NAT components

• NAT历史记录

• NAT history

• 有关 NAT 的术语和用语

• Terms and words used about NAT

• 有关 NAT 的硬件讨论

• Hardware discussions regarding NAT

• NAT 问题

• Problems with NAT

当您使用 netfilter 和 iptables 时，所有这些都将始终有用。NAT 在当今的网络中应用非常广泛，尽管它只是一个非常不幸和意外问题的中间解决方案。当我们开始更深入地研究 Linux netfilter 和 iptables 实现时，NAT 当然会在稍后更深入地讨论。

All of this will always be of use when you are working with netfilter and iptables. NAT is very widely used in today's networks, even though it is only an intermediary solution for a very unfortunate and unexpected problem. NAT will of course be discussed more in depth later on when we start looking at the Linux netfilter and iptables implementations in more depth.

哪里可以获得 iptables

Where to get iptables

iptables 用户空间包可以从http://www.netfilter.org/下载。iptables 包还利用了内核空间设施，可以在 make configure 期间将其配置到内核中。本文档将进一步讨论必要的步骤。

The iptables user-space package can be downloaded from the http://www.netfilter.org/. The iptables package also makes use of kernel space facilities which can be configured into the kernel during make configure. The necessary steps will be discussed a bit further down in this document.

内核设置

Kernel setup

要运行 iptables 的纯粹基础知识，您需要在执行 make config 或其相关命令之一时将以下选项配置到内核中：

To run the pure basics of iptables you need to configure the following options into the kernel while doing make config or one of its related commands:

CONFIG_PACKET - 此选项允许需要直接使用各种网络设备的应用程序和实用程序。此类实用程序的示例包括 tcpdump 或 snort。

CONFIG_PACKET - This option allows applications and utilities that need to work directly with various network devices. Examples of such utilities are tcpdump or snort.

严格来说，CONFIG_PACKET 是 iptables 工作所不需要的，但由于它包含如此多的用途，所以我选择将其包含在这里。如果您不想要它，请不要包含它。 CONFIG_PACKET is strictly speaking not needed for iptables to work, but since it contains so many uses, I have chosen to include it here. If you do not want it, don't include it.

CONFIG_NETFILTER - 如果您要将计算机用作防火墙或 Internet 网关，则需要此选项。换句话说，这绝对是本教程中任何内容正常工作所必需的。我想您会想要这个，因为您正在阅读本文。

CONFIG_NETFILTER - This option is required if you're going to use your computer as a firewall or gateway to the Internet. In other words, this is most definitely required for anything in this tutorial to work at all. I assume you will want this, since you are reading this.

当然，您需要添加适当的驱动程序以使您的接口正常工作，例如以太网适配器、PPP 和 SLIP 接口。上面只会添加一些iptables中的纯基础知识。老实说，你将无法做任何有成效的事情，它只是将框架添加到内核中。如果您想在 Iptables 中使用更高级的选项，您需要在内核中设置正确的配置选项。在这里，我们将向您展示基本 2.4.9 内核中可用的选项并进行简要说明：

And of course you need to add the proper drivers for your interfaces to work properly, i.e. Ethernet adapter, PPP and SLIP interfaces. The above will only add some of the pure basics in iptables. You won't be able to do anything productive to be honest, it just adds the framework to the kernel. If you want to use the more advanced options in Iptables, you need to set up the proper configuration options in your kernel. Here we will show you the options available in a basic 2.4.9 kernel and a brief explanation:

CONFIG_IP_NF_CONNTRACK - 需要此模块来进行连接跟踪。连接跟踪主要由 NAT 和伪装等使用。如果您需要对 LAN 上的计算机进行防火墙，那么您绝对应该标记此选项。例如， rc.firewall.txt脚本需要此模块才能工作。

CONFIG_IP_NF_CONNTRACK - This module is needed to make connection tracking. Connection tracking is used by, among other things, NAT and Masquerading. If you need to firewall machines on a LAN you most definitely should mark this option. For example, this module is required by the rc.firewall.txt script to work.

CONFIG_IP_NF_FTP - 如果您想在 FTP 连接上进行连接跟踪，则需要此模块。由于FTP连接在正常情况下很难进行连接跟踪，因此conntrack需要一个所谓的助手；该选项编译帮助器。如果您不添加此模块，您将无法正确通过防火墙或网关进行 FTP。

CONFIG_IP_NF_FTP - This module is required if you want to do connection tracking on FTP connections. Since FTP connections are quite hard to do connection tracking on in normal cases, conntrack needs a so called helper; this option compiles the helper. If you do not add this module you won't be able to FTP through a firewall or gateway properly.

CONFIG_IP_NF_IPTABLES - 如果您想要执行任何类型的过滤、伪装或 NAT，则需要此选项。它将整个 iptables 识别框架添加到内核中。如果没有这个，你将无法使用 iptables 做任何事情。

CONFIG_IP_NF_IPTABLES - This option is required if you want do any kind of filtering, masquerading or NAT. It adds the whole iptables identification framework to the kernel. Without this you won't be able to do anything at all with iptables.

CONFIG_IP_NF_MATCH_LIMIT - 该模块并不是完全必需的，但在示例rc.firewall.txt中使用了它。此选项提供 LIMIT 匹配，这增加了控制每分钟要匹配的数据包数量的可能性，并由适当的规则控制。例如，-m limit --limit 3/分钟将每分钟最多匹配 3 个数据包。该模块还可用于避免某些拒绝服务攻击。

CONFIG_IP_NF_MATCH_LIMIT - This module isn't exactly required but it's used in the example rc.firewall.txt. This option provides the LIMIT match, that adds the possibility to control how many packets per minute that are to be matched, governed by an appropriate rule. For example, -m limit --limit 3/minute would match a maximum of 3 packets per minute. This module can also be used to avoid certain Denial of Service attacks.

CONFIG_IP_NF_MATCH_MAC - 这允许我们根据 MA​​C 地址匹配数据包。每个以太网适配器都有自己的 MAC 地址。例如，我们可以根据所使用的 MAC 地址来阻止数据包，并且可以很好地阻止某台计算机，因为 MAC 地址很少发生变化。我们不在rc.firewall.txt示例或其他任何地方使用此选项。

CONFIG_IP_NF_MATCH_MAC - This allows us to match packets based on MAC addresses. Every Ethernet adapter has its own MAC address. We could for instance block packets based on what MAC address is used and block a certain computer pretty well since the MAC address very seldom changes. We don't use this option in the rc.firewall.txt example or anywhere else.

CONFIG_IP_NF_MATCH_MARK - 这允许我们使用 MARK 匹配。例如，如果我们使用目标 MARK，我们可以标记一个数据包，然后根据该数据包是否在表中进一步标记，我们可以根据该标记进行匹配。这个选项就是实际的匹配MARK，下面我们将描述实际的目标MARK。

CONFIG_IP_NF_MATCH_MARK - This allows us to use a MARK match. For example, if we use the target MARK we could mark a packet and then depending on if this packet is marked further on in the table, we can match based on this mark. This option is the actual match MARK, and further down we will describe the actual target MARK.

CONFIG_IP_NF_MATCH_MULTIPORT - 该模块允许我们将数据包与整个范围的目标端口或源端口进行匹配。通常这是不可能的，但在这场比赛中却是这样。

CONFIG_IP_NF_MATCH_MULTIPORT - This module allows us to match packets with a whole range of destination ports or source ports. Normally this wouldn't be possible, but with this match it is.

CONFIG_IP_NF_MATCH_TOS - 通过此匹配，我们可以根据数据包的 TOS 字段来匹配数据包。TOS 代表服务类型。TOS 还可以通过 mangle 表中的某些规则以及通过 ip/tc 命令进行设置。

CONFIG_IP_NF_MATCH_TOS - With this match we can match packets based on their TOS field. TOS stands for Type Of Service. TOS can also be set by certain rules in the mangle table and via the ip/tc commands.

CONFIG_IP_NF_MATCH_TCPMSS - 此选项增加了我们根据 TCP 数据包的 MSS 字段匹配 TCP 数据包的可能性。

CONFIG_IP_NF_MATCH_TCPMSS - This option adds the possibility for us to match TCP packets based on their MSS field.

CONFIG_IP_NF_MATCH_STATE - 与 ipchains 相比，这是最大的新闻之一。通过这个模块，我们可以对数据包进行状态匹配。例如，如果我们已经在 TCP 连接中看到两个方向的流量，则该数据包将被计为 ESTABLISHED。该模块在rc.firewall.txt示例中广泛使用。

CONFIG_IP_NF_MATCH_STATE - This is one of the biggest news in comparison to ipchains. With this module we can do stateful matching on packets. For example, if we have already seen traffic in two directions in a TCP connection, this packet will be counted as ESTABLISHED. This module is used extensively in the rc.firewall.txt example.

CONFIG_IP_NF_MATCH_UNCLEAN - 该模块将为我们添加匹配不符合类型或无效的 IP、TCP、UDP 和 ICMP 数据包的可能性。例如，我们可以丢弃这些数据包，但我们永远不知道它们是否合法。请注意，此匹配仍处于实验阶段，可能无法在所有情况下完美运行。

CONFIG_IP_NF_MATCH_UNCLEAN - This module will add the possibility for us to match IP, TCP, UDP and ICMP packets that don't conform to type or are invalid. We could for example drop these packets, but we never know if they are legitimate or not. Note that this match is still experimental and might not work perfectly in all cases.

CONFIG_IP_NF_MATCH_OWNER - 此选项将为我们添加基于套接字所有者进行匹配的可能性。例如，我们可以只允许root用户访问Internet。该模块最初只是作为新 iptables 的功能示例而编写的。请注意，此匹配仍处于实验阶段，可能并不适合所有人。

CONFIG_IP_NF_MATCH_OWNER - This option will add the possibility for us to do matching based on the owner of a socket. For example, we can allow only the user root to have Internet access. This module was originally just written as an example on what could be done with the new iptables. Note that this match is still experimental and might not work for everyone.

CONFIG_IP_NF_FILTER - 该模块将添加基本过滤表，使您能够进行 IP 过滤。在过滤器表中，您将找到 INPUT、FORWARD 和 OUTPUT 链。如果您计划对接收和发送的数据包进行任何类型的过滤，则需要此模块。

CONFIG_IP_NF_FILTER - This module will add the basic filter table which will enable you to do IP filtering at all. In the filter table you'll find the INPUT, FORWARD and OUTPUT chains. This module is required if you plan to do any kind of filtering on packets that you receive and send.

CONFIG_IP_NF_TARGET_REJECT - 这个目标允许我们指定应该发送 ICMP 错误消息来回复传入的数据包，而不是直接将它们丢弃在地板上。请记住，与 ICMP 和 UDP 不同，TCP 连接始终通过 TCP RST 数据包重置或拒绝。

CONFIG_IP_NF_TARGET_REJECT - This target allows us to specify that an ICMP error message should be sent in reply to incoming packets, instead of plainly dropping them dead to the floor. Keep in mind that TCP connections, as opposed to ICMP and UDP, are always reset or refused with a TCP RST packet.

CONFIG_IP_NF_TARGET_MIRROR - 这允许数据包被弹回到数据包的发送者。例如，如果我们在 INPUT 链上的目标端口 HTTP 上设置一个 MIRROR 目标，并且有人尝试访问该端口，我们会将他的数据包弹回给他，最后他可能会看到自己的主页。

CONFIG_IP_NF_TARGET_MIRROR - This allows packets to be bounced back to the sender of the packet. For example, if we set up a MIRROR target on destination port HTTP on our INPUT chain and someone tries to access this port, we would bounce his packets back to him and finally he would probably see his own homepage.

MIRROR 目标不能轻易使用。它最初是作为测试和示例模块构建的，对于设置它的人来说很可能非常危险（如果除其他外，还会导致严重的 DDoS）。 The MIRROR target is not to be used lightly. It was originally built as a test and example module, and will most probably be very dangerous to the person setting it up (resulting in serious DDoS if among other things).

CONFIG_IP_NF_NAT - 该模块允许不同形式的网络地址转换或 NAT。该选项使我们能够访问 iptables 中的 nat 表。如果我们想要进行端口转发、伪装等，则需要此选项。请注意，LAN 的防火墙和伪装不需要此选项，但除非您能够为所有主机提供唯一的 IP 地址，否则您应该将其设置为存在。因此，示例rc.firewall.txt脚本需要此选项才能正常工作，并且如果您无法添加上述指定的唯一 IP 地址，则肯定需要在您的网络上。

CONFIG_IP_NF_NAT - This module allows network address translation, or NAT, in its different forms. This option gives us access to the nat table in iptables. This option is required if we want to do port forwarding, masquerading, etc. Note that this option is not required for firewalling and masquerading of a LAN, but you should have it present unless you are able to provide unique IP addresses for all hosts. Hence, this option is required for the example rc.firewall.txt script to work properly, and most definitely on your network if you do not have the ability to add unique IP addresses as specified above.

CONFIG_IP_NF_TARGET_MASQUERADE - 该模块添加 MASQUERADE 目标。例如，如果我们不知道访问 Internet 的 IP 地址，那么这将是获取 IP 的首选方式，而不是使用 DNAT 或 SNAT。换句话说，如果我们使用 DHCP、PPP、SLIP 或其他为我们分配 IP 的连接，我们需要使用此目标而不是 SNAT。伪装给计算机带来的负载比 NAT 稍高，但无需我们提前知道 IP 地址即可工作。

CONFIG_IP_NF_TARGET_MASQUERADE - This module adds the MASQUERADE target. For instance if we don't know what IP we have to the Internet this would be the preferred way of getting the IP instead of using DNAT or SNAT. In other words, if we use DHCP, PPP, SLIP or some other connection that assigns us an IP, we need to use this target instead of SNAT. Masquerading gives a slightly higher load on the computer than NAT, but will work without us knowing the IP address in advance.

CONFIG_IP_NF_TARGET_REDIRECT - 例如，此目标与应用程序代理一起使用。我们不会让数据包直接通过，而是将它们重新映射到本地盒子。换句话说，我们有可能通过这种方式制作一个透明代理。

CONFIG_IP_NF_TARGET_REDIRECT - This target is useful together with application proxies, for example. Instead of letting a packet pass right through, we remap them to go to our local box instead. In other words, we have the possibility to make a transparent proxy this way.

CONFIG_IP_NF_TARGET_LOG - 这会将 LOG 目标及其功能添加到 iptables。我们可以使用此模块将某些数据包记录到 syslogd，从而查看数据包发生了什么。这对于安全审计、取证或调试您正在编写的脚本来说非常宝贵。

CONFIG_IP_NF_TARGET_LOG - This adds the LOG target and its functionality to iptables. We can use this module to log certain packets to syslogd and hence see what is happening to the packet. This is invaluable for security audits, forensics or debugging a script you are writing.

CONFIG_IP_NF_TARGET_TCPMSS - 此选项可用于对抗阻止 ICMP Fragmentation Needed 数据包的 Internet 服务提供商和服务器。这可能会导致网页无法通过、小邮件可以通过而较大的邮件则无法通过、ssh 可以工作但 scp 在握手后死掉等等。然后我们可以使用 TCPMSS 目标通过限制 MSS（最大分段大小）来克服这个问题）到 PMTU（路径最大传输单元）。

CONFIG_IP_NF_TARGET_TCPMSS - This option can be used to counter Internet Service Providers and servers who block ICMP Fragmentation Needed packets. This can result in web-pages not getting through, small mails getting through while larger mails don't, ssh works but scp dies after handshake, etc. We can then use the TCPMSS target to overcome this by clamping our MSS (Maximum Segment Size) to the PMTU (Path Maximum Transmit Unit).

CONFIG_IP_NF_COMPAT_IPCHAINS - 添加与过时的 ipchains 的兼容模式。不要将此视为解决从 Linux 2.2 内核迁移到 2.4 内核的任何真正的长期解决方案，因为它很可能随着内核 2.6 而消失。

CONFIG_IP_NF_COMPAT_IPCHAINS - Adds a compatibility mode with the obsolete ipchains. Do not look to this as any real long term solution for solving migration from Linux 2.2 kernels to 2.4 kernels, since it may well be gone with kernel 2.6.

CONFIG_IP_NF_COMPAT_IPFWADM - 与过时的 ipfwadm 的兼容模式。绝对不要将此视为真正的长期解决方案。

CONFIG_IP_NF_COMPAT_IPFWADM - Compatibility mode with obsolescent ipfwadm. Definitely don't look to this as a real long term solution.

正如您所看到的，有很多选项。我在这里简要解释了每个模块可以带来哪些额外行为。这些只是 vanilla Linux 2.4.9 内核中可用的选项。如果您想查看更多选项，我建议您查看 Netfilter 用户空间中的 patch-o-matic (POM) 函数，它将在内核中添加大量其他选项。POM 修复是应该在将来添加到内核中但尚未完全到达内核的附加内容。这可能有多种原因 - 例如补丁尚未稳定，Linus Torvalds 无法跟上，或者由于仍处于实验阶段而不想让补丁进入主流内核。

As you can see, there is a heap of options. I have briefly explained here what kind of extra behaviors you can expect from each module. These are only the options available in a vanilla Linux 2.4.9 kernel. If you would like to take a look at more options, I suggest you look at the patch-o-matic (POM) functions in Netfilter user-land which will add heaps of other options in the kernel. POM fixes are additions that are supposed to be added in the kernel in the future but have not quite reached the kernel yet. This may be for various reasons - such as the patch not being stable yet, to Linus Torvalds being unable to keep up, or not wanting to let the patch in to the mainstream kernel yet since it is still experimental.

您需要将以下选项编译到内核中或作为模块，以便rc.firewall.txt脚本正常工作。如果您需要其他脚本所需选项的帮助，请查看示例防火墙脚本部分。

You will need the following options compiled into your kernel, or as modules, for the rc.firewall.txt script to work. If you need help with the options that the other scripts need, look at the example firewall scripts section.

• 配置数据包

• CONFIG_PACKET

• 配置网络过滤器

• CONFIG_NETFILTER

• CONFIG_IP_NF_CONNTRACK

• CONFIG_IP_NF_CONNTRACK

• 配置_IP_NF_FTP

• CONFIG_IP_NF_FTP

• 配置_IP_NF_IRC

• CONFIG_IP_NF_IRC

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_FILTER

• CONFIG_IP_NF_FILTER

• 配置_IP_NF_NAT

• CONFIG_IP_NF_NAT

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_TARGET_LOG

• CONFIG_IP_NF_TARGET_LOG

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_TARGET_MASQUERADE

• CONFIG_IP_NF_TARGET_MASQUERADE

至少rc.firewall.txt脚本需要上述内容。在其他示例脚本中，我将解释它们在各自部分中的要求。现在，让我们尝试将注意力集中在您现在应该学习的主要脚本上。

At the very least the above will be required for the rc.firewall.txt script. In the other example scripts I will explain what requirements they have in their respective sections. For now, let's try to stay focused on the main script which you should be studying now.

用户态设置

User-land setup

首先我们看一下iptables包是如何编译的。重要的是要认识到，在大多数情况下，iptables 的配置和编译与内核配置和编译是密切相关的。某些发行版预装了 iptables 软件包，其中之一是 Red Hat。然而，在旧版 Red Hat 中，它默认被禁用。我们将在本章中仔细检查如何启用它并进一步了解其他发行版。

First of all, let's look at how we compile the iptables package. It's important to realize that for the most part configuration and compilation of iptables goes hand in hand with the kernel configuration and compilation. Certain distributions come with the iptables package preinstalled, one of these is Red Hat. However, in old Red Hat it is disabled per default. We will check closer on how to enable it and take a look at other distributions further on in this chapter.

---

编译用户态应用程序

Compiling the user-land applications

首先解压 iptables 包。在这里，我们使用了iptables 1.2.6a软件包和 vanilla 2.4 内核。像平常一样解压，使用 bzip2 -cd iptables-1.2.6a.tar.bz2 | tar -xvf - （这也可以使用 tar -xjvf iptables-1.2.6a.tar.bz2 来完成，它的作用与第一个命令几乎相同。但是，这可能不适用于旧版本的 tar）。该包现在应该正确解压到名为 iptables-1.2.6a 的目录中。有关更多信息，请阅读iptables-1.2.6a/INSTALL 文件，其中包含有关编译和运行程序的非常好的信息。

First of all unpack the iptables package. Here, we have used the iptables 1.2.6a package and a vanilla 2.4 kernel. Unpack as usual, using bzip2 -cd iptables-1.2.6a.tar.bz2 | tar -xvf - (this can also be accomplished with the tar -xjvf iptables-1.2.6a.tar.bz2, which should do pretty much the same as the first command. However, this may not work with older versions of tar). The package should now be unpacked properly into a directory named iptables-1.2.6a. For more information read the iptables-1.2.6a/INSTALL file which contains pretty good information on compiling and getting the program to run.

之后，您可以选择为内核配置和安装额外的模块和选项等。此处描述的步骤将仅检查和安装待包含到内核中的标准补丁，还有一些更多的实验性补丁，这可能仅在您执行其他步骤时可用。

After this, there you have the option of configuring and installing extra modules and options etcetera for the kernel.The step described here will only check and install standard patches that are pending for inclusion to the kernel, there are some even more experimental patches further along, which may only be available when you carry out other steps.

其中一些补丁是高度实验性的，安装它们可能不是一个好主意。然而，在这个安装步骤中有很多非常有趣的匹配和目标，所以不要害怕，至少看看它们。 Some of these patches are highly experimental and may not be such a good idea to install them. However, there are heaps of extremely interesting matches and targets in this installation step so don't be afraid of at least looking at them. 为了执行此步骤，我们从 iptables 包的根目录执行以下操作： To carry out this step we do something like this from the root of the iptables package:

制作待处理补丁 KERNEL_DIR=/usr/src/linux/

make pending-patches KERNEL_DIR=/usr/src/linux/

该变量KERNEL_DIR应该指向内核源代码所在的实际位置。通常这应该是 /usr/src/linux/，但是这可能会有所不同，并且很可能您会知道内核源代码在哪里可用。

The variable KERNEL_DIR should point to the actual place that your kernel source is located at. Normally this should be /usr/src/linux/ but this may vary, and most probably you will know yourself where the kernel source is available.

上面的命令只询问某些即将进入内核的补丁。Netfilter 的开发人员可能会向内核添加更多补丁和附加内容，但距离实际实现还有点距离。安装这些的一种方法是执行以下操作：

The above command only asks about certain patches that are just about to enter the kernel anyway. There might be more patches and additions that the developers of Netfilter are about to add to the kernel, but is a bit further away from actually getting there. One way to install these is by doing the following:

制作大部分 pom KERNEL_DIR=/usr/src/linux/

make most-of-pom KERNEL_DIR=/usr/src/linux/

上面的命令会询问安装 Netfilter 世界中称为 patch-o-matic 的部分内容，但仍然跳过可能对内核造成严重破坏的最极端的补丁。请注意，我们说“询问”，因为这就是这些命令实际执行的操作。在内核源代码发生任何更改之前，他们会询问您。为了能够安装 所有patch-o-matic 的东西，您需要运行以下命令：

The above command would ask about installing parts of what in Netfilter world is called patch-o-matic, but still skip the most extreme patches that might cause havoc in your kernel. Note that we say ask, because that's what these commands actually do. They ask you before anything is changed in the kernel source. To be able to install all of the patch-o-matic stuff you will need to run the following command:

制作 patch-o-matic KERNEL_DIR=/usr/src/linux/

make patch-o-matic KERNEL_DIR=/usr/src/linux/

在执行任何操作之前，请不要忘记彻底阅读每个补丁的帮助。有些补丁会破坏其他补丁，而另一些补丁如果与 patch-o-matic 等的某些补丁一起使用，可能会破坏您的内核。

Don't forget to read the help for each patch thoroughly before doing anything. Some patches will destroy other patches while others may destroy your kernel if used together with some patches from patch-o-matic etc.

如果您不想修补内核，您可以完全忽略上述步骤，换句话说，没有必要执行上述操作。然而，patch-o-matic 中有一些非常有趣的东西，您可能想看看，因此运行命令并查看它们包含的内容并没有什么不好。 You may totally ignore the above steps if you don't want to patch your kernel, it is in other words not necessary to do the above. However, there are some really interesting things in the patch-o-matic that you may want to look at so there's nothing bad in just running the commands and see what they contain.

完成安装的 patch-o-matic 部分之后，您现在可以使用已添加到源中的新补丁来编译新内核。不要忘记再次配置内核，因为新补丁可能不会添加到配置的选项中。不过，如果您愿意，可以等到用户态程序 iptables 编译完成后才进行内核编译。

After this you are finished doing the patch-o-matic parts of installation, you may now compile a new kernel making use of the new patches that you have added to the source. Don't forget to configure the kernel again since the new patches probably are not added to the configured options. You may wait with the kernel compilation until after the compilation of the user-land program iptables if you feel like it, though.

继续编译 iptables 用户态应用程序。要编译 iptables，您可以发出如下所示的简单命令：

Continue by compiling the iptables user-land application. To compile iptables you issue a simple command that looks like this:

使 KERNEL_DIR=/usr/src/linux/

make KERNEL_DIR=/usr/src/linux/

用户态应用程序现在应该可以正确编译。如果没有，您就得靠自己了，或者您可以订阅Netfilter 邮件列表，在那里您有机会就您的问题寻求帮助。iptables 的安装可能会出现一些问题，所以如果它不起作用也不要惊慌。尝试逻辑思考并找出问题所在，或者请人帮助您。

The user-land application should now compile properly. If not, you are on your own, or you could subscribe to the Netfilter mailing list, where you have the chance of asking for help with your problems. There are a few things that might go wrong with the installation of iptables, so don't panic if it won't work. Try to think logically about it and find out what's wrong, or get someone to help you.

如果一切顺利，您现在就可以安装二进制文件了。为此，您需要发出以下命令来安装它们：

If everything has worked smoothly, you're ready to install the binaries by now. To do this, you would issue the following command to install them:

make install KERNEL_DIR=/usr/src/linux/

make install KERNEL_DIR=/usr/src/linux/

希望现在程序中一切都可以正常工作。要使用 iptables 用户态应用程序中的任何更改，您现在应该重新编译并重新安装内核和模块（如果您之前没有这样做）。有关从源安装用户态应用程序的更多信息，请检查源中的 INSTALL文件，其中包含有关安装主题的精彩信息。

Hopefully everything should work in the program now. To use any of the changes in the iptables user-land applications you should now recompile and reinstall your kernel and modules, if you hadn't done so before. For more information about installing the user-land applications from source, check the INSTALL file in the source which contains excellent information on the subject of installation.

---

在 Red Hat 7.1 上安装

Installation on Red Hat 7.1

Red Hat 7.1 预装了 2.4.x 内核，其中编译了 Netfilter 和 iptables。它还包含运行它所需的所有基本用户态程序和配置文件。然而，红帽人员通过使用向后兼容的 ipchains 模块禁用了整个功能。至少可以说很烦人，很多人不断询问不同的邮件列表为什么 iptables 不起作用。那么，让我们简要了解一下如何关闭 ipchains 模块以及如何安装 iptables。

Red Hat 7.1 comes preinstalled with a 2.4.x kernel that has Netfilter and iptables compiled in. It also contains all the basic user-land programs and configuration files that are needed to run it. However, the Red Hat people have disabled the whole thing by using the backward compatible ipchains module. Annoying to say the least, and a lot of people keep asking different mailing lists why iptables doesn't work. So, let's take a brief look at how to turn the ipchains module off and how to install iptables instead.

今天默认的 Red Hat 7.1 安装附带了用户空间应用程序的旧版本，因此您可能需要编译新版本的应用程序，并在完全利用 iptables 之前安装新的自定义编译内核。 The default Red Hat 7.1 installation today comes with a hopelessly old version of the user-space applications, so you might want to compile a new version of the applications as well as install a new and custom compiled kernel before fully exploiting iptables.

首先，您需要关闭 ipchains 模块，这样它以后就不会启动。为此，您需要更改/etc/rc.d/目录结构中的一些文件名。以下命令应该可以做到这一点：

First of all you will need to turn off the ipchains modules so it won't start in the future. To do this, you will need to change some filenames in the /etc/rc.d/ directory-structure. The following command should do it:

chkconfig --level 0123456 ipchains 关闭

chkconfig --level 0123456 ipchains off

通过这样做，我们将所有指向/etc/rc.d/init.d/ipchains脚本的软链接移动 到 K92ipchains。第一个字母默认为 S，告诉 initscripts 启动脚本。通过将其更改为 K，我们告诉它终止该服务，或者如果之前未启动该服务则不运行它。现在该服务将来不会启动。

By doing this we move all the soft links that points to the /etc/rc.d/init.d/ipchains script to K92ipchains. The first letter which per default would be S, tells the initscripts to start the script. By changing this to K we tell it to Kill the service instead, or to not run it if it was not previously started. Now the service won't be started in the future.

但是，要立即停止服务的实际运行，我们需要运行另一个命令。这是可用于处理当前正在运行的服务的服务命令。然后我们将发出以下命令来停止 ipchains 服务：

However, to stop the service from actually running right now we need to run another command. This is the service command which can be used to work on currently running services. We would then issue the following command to stop the ipchains service:

服务 ipchains 停止

service ipchains stop

最后，启动iptables服务。首先，我们需要知道我们希望它运行在哪个运行级别。通常情况下，这将是运行级别 2、3 和 5。这些运行级别用于以下用途：

Finally, to start the iptables service. First of all, we need to know which run-levels we want it to run in. Normally this would be in run-level 2, 3 and 5. These run-levels are used for the following things:

• 2. 没有 NFS 的多用户，或者如果没有网络则与 3 相同。

• 2. Multiuser without NFS or the same as 3 if there is no networking.

• 3. 完全多用户模式，即运行的正常运行级别。

• 3. Full multiuser mode, i.e. the normal run-level to run in.

• 5.X11。如果您自动启动到 Xwindows，则使用此选项。

• 5. X11. This is used if you automatically boot into Xwindows.

要使 iptables 在这些运行级别中运行，我们将执行以下命令：

To make iptables run in these run-levels we would do the following commands:

chkconfig --level 235 iptables 打开

chkconfig --level 235 iptables on

换句话说，上述命令将使 iptables 服务在运行级别 2、3 和 5 中运行。如果您希望 iptables 服务在其他运行级别中运行，则必须在这些运行级别中发出相同的命令。但是，不应使用任何其他运行级别，因此您实际上不需要为这些运行级别激活它。1 级适用于单用户模式，即当您需要修理一个拧坏的盒子时。级别 4 应该未使用，级别 6 用于关闭计算机。

The above commands would in other words make the iptables service run in run-level 2, 3 and 5. If you'd like the iptables service to run in some other run-level you would have to issue the same command in those. However, none of the other run-levels should be used, so you should not really need to activate it for those run-levels. Level 1 is for single user mode, i.e, when you need to fix a screwedup box. Level 4 should be unused, and level 6 is for shutting the computer down.

要激活 iptables 服务，我们只需运行以下命令：

To activate the iptables service, we just run the following command:

服务 iptables 启动

service iptables start

iptables 脚本中没有规则。要将规则添加到 Red Hat 7.1 盒子，有两种常见的方法。首先，您可以编辑/etc/rc.d/init.d/iptables脚本。如果您通过 RPM 更新了 iptables 软件包，这会产生删除所有规则的不良效果。另一种方法是加载规则集，然后使用 iptables-save 命令保存它，然后由 rc.d 脚本自动加载。

There are no rules in the iptables script. To add rules to an Red Hat 7.1 box, there is two common ways. Firstly, you could edit the /etc/rc.d/init.d/iptables script. This would have the undesired effect of deleting all the rules if you updated the iptables package by RPM. The other way would be to load the rule-set and then save it with the iptables-save command and then have it loaded automatically by the rc.d scripts.

首先，我们将描述如何通过剪切并粘贴到 iptables init.d 脚本来设置 iptables。要添加计算机启动服务时要运行的规则，请将它们添加到 start) 部分下或 start() 函数中。请注意，如果您在 start) 部分添加规则，请不要忘记停止 start) 部分中的 start() 函数运行。另外，不要忘记编辑 stop) 部分，它告诉脚本当计算机停机时或当我们进入不需要 iptables 的运行级别时要做什么。另外，不要忘记检查重新启动部分和 condrestart。请注意，如果您有（例如，Red Hat Network）自动更新您的软件包，所有这些工作可能都会被浪费。它也可能通过从 iptables RPM 包更新而被废弃。

First we will describe the how to set up iptables by cutting and pasting to the iptables init.d script. To add rules that are to be run when the computer starts the service, you add them under the start) section, or in the start() function. Note, if you add the rules under the start) section don't forget to stop the start() function in the start) section from running. Also, don't forget to edit a the stop) section either which tells the script what to do when the computer is going down for example, or when we are entering a run-level that doesn't require iptables. Also, don't forget to check out the restart section and condrestart. Note that all this work will probably be trashed if you have, for example, Red Hat Network automatically update your packages. It may also be trashed by updating from the iptables RPM package.

第二种设置方法需要执行以下操作：首先，在 shell 脚本文件中创建并编写规则集，或者直接使用 iptables，这将满足您的要求，并且不要忘记进行一些实验。当您发现设置可以正常工作，或者您可以看到没有错误时，请使用 iptables-save 命令。您可以正常使用它，即 iptables-save > /etc/sysconfig/iptables ，这会将规则集保存到文件/etc/sysconfig/iptables中。iptables rc.d 脚本会自动使用此文件来恢复将来的规则集。另一种方法是通过执行 service iptables save 来保存脚本，这会将脚本自动保存到/etc/sysconfig/iptables。下次重新启动计算机时，iptables rc.d 脚本将使用命令 iptables-restore 从保存文件/etc/sysconfig/iptables恢复规则集。不要混合使用这两种方法，因为它们可能会严重损害彼此并使您的防火墙配置变得无用。

The second way of doing the set up would require the following: First of all, make and write a rule-set in a shell script file, or directly with iptables, that will meet your requirements, and don't forget to experiment a bit. When you find a set up that works without problems, or as you can see without bugs, use the iptables-save command. You could either use it normally, i.e. iptables-save > /etc/sysconfig/iptables, which would save the rule-set to the file /etc/sysconfig/iptables. This file is automatically used by the iptables rc.d script to restore the rule-set in the future. The other way is to save the script by doing service iptables save, which would save the script automatically to /etc/sysconfig/iptables. The next time you reboot the computer, the iptables rc.d script will use the command iptables-restore to restore the rule-set from the save-file /etc/sysconfig/iptables. Do not intermix these two methods, since they may heavily damage each other and render your firewall configuration useless.

完成所有这些步骤后，您可以卸载当前安装的 ipchains 和 iptables 软件包。这是因为我们不希望系统将新的 iptables 用户态应用程序与旧的预安装 iptables 应用程序混合在一起。仅当您要从源包安装 iptables 时才需要执行此步骤。新旧软件包混淆的情况并不罕见，因为基于 rpm 的安装将软件包安装在非标准位置，并且不会被新 iptables 软件包的安装覆盖。要执行卸载，请执行以下操作：

When all of these steps are finished, you can deinstall the currently installed ipchains and iptables packages. This because we don't want the system to mix up the new iptables user-land application with the old preinstalled iptables applications. This step is only necessary if you are going to install iptables from the source package. It's not unusual for the new and the old package to get mixed up, since the rpm based installation installs the package in non-standard places and won't get overwritten by the installation for the new iptables package. To carry out the deinstallation, do as follows:

rpm -e iptables

rpm -e iptables

如果您不再使用 ipchains，为什么还要保留它呢？删除它的方式与旧的 iptables 二进制文件等相同：

And why keep ipchains lying around if you won't be using it any more? Removing it is done the same way as with the old iptables binaries, etc:

rpm -e ipchains

rpm -e ipchains

完成所有这些后，您将按照源安装说明完成 iptables 软件包的源更新。任何旧的二进制文件、库或包含文件等都不应再存在。

After all this has been completed, you will have finished with the update of the iptables package from source, having followed the source installation instructions. None of the old binaries, libraries or include files etc should be lying around any more.

下一步是什么？

What's next?

本章讨论了如何在一些常见平台上获取和安装 iptables 和 netfilter。在大多数现代 Linux 发行版中，iptables 都会默认安装，但有时可能需要编译自己的内核和 iptables 二进制文件才能获得绝对最新的更新。本章应该对管理这个问题有一点帮助。

This chapter has discussed how to get and how to install iptables and netfilter on some common platforms. In most modern Linux distributions iptables will come with the default installation, but sometimes it might be necessary to compile your own kernel and iptables binaries to get the absolutely latest updates. This chapter should have been a small help managing this.

下一章将讨论如何遍历表和链，以及遍历的顺序等等。理解这一点对于将来能够构建自己的工作规则集非常重要。所有不同的表也将进行深入讨论，因为它们是为了不同的目的而创建的。

The next chapter will discuss how tables and chains are traversed, and in what order this happens and so forth. This is very important to comprehend to be able to build your own working rulesets in the future. All the different tables will be discussed in some depth also since they are created for different purposes.

一般的

General

当数据包首次进入防火墙时，它会到达硬件，然后传递到内核中正确的设备驱动程序。然后，数据包开始在内核中执行一系列步骤，然后将其发送到正确的应用程序（本地），或转发到另一台主机 - 或发生任何情况。

When a packet first enters the firewall, it hits the hardware and then gets passed on to the proper device driver in the kernel. Then the packet starts to go through a series of steps in the kernel, before it is either sent to the correct application (locally), or forwarded to another host - or whatever happens to it.

首先，让我们看一下发往我们自己的本地主机的数据包。在实际交付给我们接收它的应用程序之前，它将经过以下步骤：

First, let us have a look at a packet that is destined for our own local host. It would pass through the following steps before actually being delivered to our application that receives it:

请注意，这次数据包是通过 INPUT 链而不是 FORWARD 链传递的。很有逻辑。很可能一开始你眼中唯一真正符合逻辑的就是遍历表和链，但是如果你继续思考它，你会发现随着时间的推移它会变得更加清晰。

Note that this time the packet was passed through the INPUT chain instead of the FORWARD chain. Quite logical. Most probably the only thing that's really logical about the traversing of tables and chains in your eyes in the beginning, but if you continue to think about it, you'll find it will get clearer in time.

现在我们看看从我们自己的本地主机发出的数据包以及它们经历了哪些步骤。

Now we look at the outgoing packets from our own local host and what steps they go through.

在此示例中，我们假设数据包的目的地是另一个网络上的另一台主机。数据包按以下方式经历不同的步骤：

In this example, we're assuming that the packet is destined for another host on another network. The packet goes through the different steps in the following fashion:

正如您所看到的，需要经过很多步骤。数据包可以在任何 iptables 链上停止，如果格式错误，也可以在其他任何地方停止；然而，我们主要对这个批次的 iptables 方面感兴趣。请注意，对于不同的接口或类似的东西，没有特定的链或表。通过此防火墙/路由器转发的所有数据包始终都会通过 FORWARD。

As you can see, there are quite a lot of steps to pass through. The packet can be stopped at any of the iptables chains, or anywhere else if it is malformed; however, we are mainly interested in the iptables aspect of this lot. Do note that there are no specific chains or tables for different interfaces or anything like that. FORWARD is always passed by all packets that are forwarded over this firewall/router.

在前面的场景中不要使用 INPUT 链进行过滤！INPUT 仅适用于发送至本地主机且不会路由至任何其他目的地的数据包。 Do not use the INPUT chain to filter on in the previous scenario! INPUT is meant solely for packets to our local host that do not get routed to any other destination.

我们现在已经看到了如何在三个不同的场景中遍历不同的链。如果我们要绘制出所有这一切的一张好的地图，它看起来会像这样：

We have now seen how the different chains are traversed in three separate scenarios. If we were to figure out a good map of all this, it would look something like this:

为了澄清这个图像，请考虑这一点。如果我们将一个数据包放入第一个路由决策中，但该数据包的目的地不是本地计算机本身，它将通过 FORWARD 链进行路由。另一方面，如果数据包的目的地是本地计算机正在侦听的 IP 地址，我们将通过 INPUT 链将数据包发送到本地计算机。

To clarify this image, consider this. If we get a packet into the first routing decision that is not destined for the local machine itself, it will be routed through the FORWARD chain. If the packet is, on the other hand, destined for an IP address that the local machine is listening to, we would send the packet through the INPUT chain and to the local machine.

另外值得注意的是，数据包的目的地可能是本地计算机，但目标地址可能会通过执行 NAT 在 PREROUTING 链内更改。由于这是在第一个路由决策之前发生的，因此将在此更改之后查看数据包。因此，在路由决策完成之前，路由可能会发生变化。请注意， 所有数据包都将通过该图像中的一个或另一条路径。如果您将数据包 DNAT 回到它来自的同一网络，它仍然会穿过其余的链，直到它回到网络上。

Also worth a note, is the fact that packets may be destined for the local machine, but the destination address may be changed within the PREROUTING chain by doing NAT. Since this takes place before the first routing decision, the packet will be looked upon after this change. Because of this, the routing may be changed before the routing decision is done. Do note, that all packets will be going through one or the other path in this image. If you DNAT a packet back to the same network that it came from, it will still travel through the rest of the chains until it is back out on the network.

如果您觉得需要更多信息，可以使用rc.test-iptables.txt 脚本。该测试脚本应该为您提供必要的规则来测试如何遍历表和链。 If you feel that you want more information, you could use the rc.test-iptables.txt script. This test script should give you the necessary rules to test how the tables and chains are traversed.

轧布台

Mangle table

正如我们已经指出的，该表主要用于修改数据包。换句话说，您可以自由地使用该表中的 mangle 目标，更改 TOS（服务类型）字段等。

This table should as we've already noted mainly be used for mangling packets. In other words, you may freely use the mangle targets within this table, to change TOS (Type Of Service) fields and the like.

强烈建议您不要使用此表进行任何过滤；任何 DNAT、SNAT 或伪装在此表中都不起作用。 You are strongly advised not to use this table for any filtering; nor will any DNAT, SNAT or Masquerading work in this table.

以下目标仅在 mangle 表中有效。它们不能在 mangle 表之外使用。

The following targets are only valid in the mangle table. They can not be used outside the mangle table.

• 服务条款

• TOS

• TTL

• TTL

• 标记

• MARK

• 塞克马克

• SECMARK

• 康涅狄格州标志

• CONNSECMARK

TOS 目标用于设置和/或更改数据包中的服务类型字段。这可用于在网络上设置有关如何路由数据包的策略等。请注意，这还没有完善，并且没有在互联网上真正实现，并且大多数路由器并不关心该字段中的值，有时，它们对所得到的内容表现出错误。换句话说，除非您想使用 iproute2 对其进行路由决策，否则不要为发送到 Internet 的数据包设置此项。

The TOS target is used to set and/or change the Type of Service field in the packet. This could be used for setting up policies on the network regarding how a packet should be routed and so on. Note that this has not been perfected and is not really implemented on the Internet and most of the routers don't care about the value in this field, and sometimes, they act faulty on what they get. Don't set this in other words for packets going to the Internet unless you want to make routing decisions on it, with iproute2.

TTL 目标用于更改数据包的 TTL（生存时间）字段。我们可以告诉数据包仅具有特定的 TTL 等等。这样做的一个很好的原因可能是我们不想把自己暴露给爱管闲事的互联网服务提供商。一些互联网服务提供商不喜欢用户在一个连接上运行多台计算机，并且已知一些互联网服务提供商会寻找生成不同 TTL 值的单个主机，并将其视为多台计算机连接到单个连接的众多标志之一。联系。

The TTL target is used to change the TTL (Time To Live) field of the packet. We could tell packets to only have a specific TTL and so on. One good reason for this could be that we don't want to give ourself away to nosy Internet Service Providers. Some Internet Service Providers do not like users running multiple computers on one single connection, and there are some Internet Service Providers known to look for a single host generating different TTL values, and take this as one of many signs of multiple computers connected to a single connection.

MARK 目标用于为数据包设置特殊标记值。然后 iproute2 程序可以识别这些标记，以便根据它们具有或不具有的标记对数据包执行不同的路由。我们还可以根据这些标记进行带宽限制和基于类的排队。

The MARK target is used to set special mark values to the packet. These marks could then be recognized by the iproute2 programs to do different routing on the packet depending on what mark they have, or if they don't have any. We could also do bandwidth limiting and Class Based Queuing based on these marks.

SECMARK 目标可用于在单个数据包上设置安全上下文标记，以便在 SELinux 和其他能够处理这些标记的安全系统中使用。然后，这用于非常细粒度的安全性，确定系统的哪些子系统可以接触哪些数据包等。SECMARK 还可以在与 CONNSECMARK 目标的整个连接上设置。

The SECMARK target can be used to set security context marks on single packets for usage in SELinux and other security systems that are able to handle these marks. This is then used for very fine grained security on what subsystems of the system can touch what packets et cetera. The SECMARK can also be set on a whole connection with the CONNSECMARK target.

CONNSECMARK 用于将安全上下文复制到整个连接的单个数据包或从整个连接的单个数据包复制安全上下文。然后，SELinux 和其他安全系统使用它在连接级别上执行更细粒度的安全性。

CONNSECMARK is used to copy a security context to or from a single packet from or to the whole connection. This is then used by the SELinux and other security systems to do more fine-grained security on a connection level.

自然表

Nat table

该表只能用于不同数据包上的 NAT（网络地址转换）。换句话说，它只能用于转换数据包的源字段或目标字段。请注意，正如我们之前所说，只有流中的第一个数据包才会到达该表。此后，其余数据包将自动执行与第一个数据包相同的操作。做这些事情的实际目标是：

This table should only be used for NAT (Network Address Translation) on different packets. In other words, it should only be used to translate the packet's source field or destination field. Note that, as we have said before, only the first packet in a stream will hit this table. After this, the rest of the packets will automatically have the same action taken on them as the first packet. The actual targets that do these kind of things are:

• DNAT

• DNAT

• 网络地址转换

• SNAT

• 假面舞会

• MASQUERADE

• 重定向

• REDIRECT

DNAT 目标主要用于您拥有公共 IP 并希望将对防火墙的访问重定向到其他主机（例如在 DMZ 上）的情况。换句话说，我们更改数据包的目标地址并将其重新路由到主机。

The DNAT target is mainly used in cases where you have a public IP and want to redirect accesses to the firewall to some other host (on a DMZ for example). In other words, we change the destination address of the packet and reroute it to the host.

SNAT主要用于改变报文的源地址。大多数情况下，您将隐藏本地网络或 DMZ 等。一个很好的例子是我们知道外部 IP 地址的防火墙，但需要用防火墙的 IP 号替换本地网络的 IP 号。通过此目标，防火墙将自动对数据包进行 SNAT 和 De-SNAT，从而可以建立从 LAN 到 Internet 的连接。例如，如果您的网络使用 192.168.0.0/netmask，则数据包将永远不会从 Internet 取回，因为 IANA 已将这些网络（以及其他网络）规定为私有网络，并且只能在隔离的 LAN 中使用。

SNAT is mainly used for changing the source address of packets. For the most part you'll hide your local networks or DMZ, etc. A very good example would be that of a firewall of which we know outside IP address, but need to substitute our local network's IP numbers with that of our firewall. With this target the firewall will automatically SNAT and De-SNAT the packets, hence making it possible to make connections from the LAN to the Internet. If your network uses 192.168.0.0/netmask for example, the packets would never get back from the Internet, because IANA has regulated these networks (among others) as private and only for use in isolated LANs.

MASQUERADE 目标的使用方式与 SNAT 完全相同，但 MASQUERADE 目标需要更多的计算开销。原因是每次 MASQUERADE 目标被数据包命中时，它都会自动检查要使用的 IP 地址，而不是像 SNAT 目标那样 - 只使用单个配置的 IP 地址。MASQUERADE 目标可以与您的 ISP 可能为您的 PPP、PPPoE 或 SLIP 连接到 Internet 的动态 DHCP IP 地址正常工作。

The MASQUERADE target is used in exactly the same way as SNAT, but the MASQUERADE target takes a little bit more overhead to compute. The reason for this, is that each time that the MASQUERADE target gets hit by a packet, it automatically checks for the IP address to use, instead of doing as the SNAT target does - just using the single configured IP address. The MASQUERADE target makes it possible to work properly with Dynamic DHCP IP addresses that your ISP might provide for your PPP, PPPoE or SLIP connections to the Internet.

原始表

Raw table

原始表主要仅用于一件事，那就是在数据包上设置一个标记，表明它们不应由连接跟踪系统处理。这是通过在数据包上使用 NOTRACK 目标来完成的。如果连接被 NOTRACK 目标命中，那么 conntrack 将不会跟踪该连接。如果不添加新表，这是不可能解决的，因为只有在 conntrack 实际在数据包上运行并添加到 conntrack 表中或与已可用的连接进行匹配之后，才会调用其他表。您可以在状态机章节中阅读更多相关内容 。

The raw table is mainly only used for one thing, and that is to set a mark on packets that they should not be handled by the connection tracking system. This is done by using the NOTRACK target on the packet. If a connection is hit with the NOTRACK target, then conntrack will simply not track the connection. This has been impossible to solve without adding a new table, since none of the other tables are called until after conntrack has actually been run on the packets, and been added to the conntrack tables, or matched against an already available connection. You can read more about this in the The state machine chapter.

该表只有 PREROUTING 和 OUTPUT 链。不需要其他链，因为这些是在数据包实际到达连接跟踪之前可以处理数据包的唯一位置。

This table only has the PREROUTING and OUTPUT chains. No other chains are required since these are the only places that you can deal with packets before they actually hit the connection tracking.

为了使该表正常工作，必须加载 iptable_raw 模块。如果 iptables 使用 -t raw 关键字运行并且该模块可用，它将自动加载。 For this table to work, the iptable_raw module must be loaded. It will be loaded automatically if iptables is run with the -t raw keywords, and if the module is available.

raw 表是 iptables 和内核中相对较新的补充。除非修补，否则它可能在早期 2.6 和 2.4 内核中不可用。 The raw table is a relatively new addition to iptables and the kernel. It might not be available in early 2.6 and 2.4 kernels unless patched.

过滤表

Filter table

过滤表主要用于过滤数据包。我们可以以任何我们想要的方式匹配数据包并过滤它们。这是我们实际对数据包采取操作并查看它们包含的内容并根据其内容丢弃或/接受它们的地方。当然我们也可以做事前过滤；然而，这个特定的表是设计过滤的地方。几乎所有目标都可以在此表中使用。我们将在这里更加丰富地介绍过滤表；但是您现在知道该表是进行主要过滤的正确位置。

The filter table is mainly used for filtering packets. We can match packets and filter them in whatever way we want. This is the place that we actually take action against packets and look at what they contain and DROP or /ACCEPT them, depending on their content. Of course we may also do prior filtering; however, this particular table is the place for which filtering was designed. Almost all targets are usable in this table. We will be more prolific about the filter table here; however you now know that this table is the right place to do your main filtering.

用户指定链

User specified chains

如果数据包进入过滤表中的INPUT链等链，我们可以指定跳转规则到同一个表中的不同链。新链必须由用户指定，它可能不是内置链，例如 INPUT 或 FORWARD 链。如果我们考虑一个指向链中要执行的规则的指针，该指针将从一个规则到另一个规则，从上到下，直到链遍历由目标或主链结束（即，FORWARD，INPUT，等等）结束。一旦发生这种情况，将应用内置链的默认策略。

If a packet enters a chain such as the INPUT chain in the filter table, we can specify a jump rule to a different chain within the same table. The new chain must be userspecified, it may not be a built-in chain such as the INPUT or FORWARD chain for example. If we consider a pointer pointing at the rule in the chain to execute, the pointer will go down from rule to rule, from top to bottom until the chain traversal is either ended by a target or the main chain (I.e., FORWARD, INPUT, et cetera) ends. Once this happens, the default policy of the built-in chain will be applied.

如果匹配的规则之一指向跳转规范中的另一个用户指定的链，则指针将跳转到该链，然后开始从上到下遍历该链。例如，看看上图中规则执行如何从规则号 3 跳转到链 2。该数据包与规则 3 中包含的匹配项相匹配，并且跳转/目标规范被设置为发送该数据包以在链 2 中进行进一步检查。

If one of the rules that matches points to another userspecified chain in the jump specification, the pointer will jump over to this chain and then start traversing that chain from the top to bottom. For example, see how the rule execution jumps from rule number 3 to chain 2 in the above image. The packet matched the matches contained in rule 3, and the jump/target specification was set to send the packet on for further examination in chain 2.

用户指定的链在链的末端不能有默认策略。只有内置链才能有这个。可以通过在链末尾附加一条没有匹配项的单个规则来避免这种情况，因此它将表现为默认策略。如果用户指定的链中没有匹配规则，则默认行为是跳回原始链。如上图所示，规则执行从链 2 跳转回链 1 规则 4，位于最初将规则执行发送到链 2 的规则下方。 Userspecified chains can not have a default policy at the end of the chain. Only built in chains can have this. This can be circumvented by appending a single rule at the end of the chain that has no matches, and hence it will behave as a default policy. If no rule is matched in a userspecified chain, the default behaviour is to jump back to the originating chain. As seen in the image above, the rule execution jumps from chain 2 and back to chain 1 rule 4, below the rule that sent the rule execution into chain 2 to begin with.

遍历用户指定的链中的每条规则，直到其中一个规则匹配为止——然后目标指定遍历应该结束还是继续——或者到达链的末尾。如果到达用户指定链的末尾，则数据包将被发送回调用链。调用链可以是用户指定的链，也可以是内置的链。

Each and every rule in the user specified chain is traversed until either one of the rules matches -- then the target specifies if the traversing should end or continue -- or the end of the chain is reached. If the end of the user specified chain is reached, the packet is sent back to the invoking chain. The invoking chain can be either a user specified chain or a built-in chain.

下一步是什么？

What's next?

在本章中，我们讨论了一些链和表以及它们是如何遍历的，包括标准内置链和用户指定的链。这是一个需要理解的非常重要的领域。这可能很简单，但除非完全理解，否则同样容易犯致命错误。

In this chapter we have discussed several of the chains and tables and how they are traversed, including the standard built-in chains and userspecified chains. This is a very important area to understand. It may be simple, but unless fully understood, fatal mistakes can be equally easily.

下一章将深入讨论 netfilter 的状态机，以及如何在连接跟踪机中遍历数据包并设置状态。换句话说，下一章与本章一样重要。

The next chapter will deal in depth with the state machine of netfilter, and how states are traversed and set on packets in a connection tracking machine. The next chapter is in other words just as important as this chapter has been.

介绍

Introduction

状态机是 iptables 中的一个特殊部分，实际上根本不应该称为状态机，因为它实际上是一个连接跟踪机。然而，大多数人都通过名字认出它。在本章中，我将或多或少地使用这些名称，就好像它们是同义词一样。这不应该过于混乱。连接跟踪的目的是让 Netfilter 框架了解特定连接的状态。实现这一点的防火墙通常称为状态防火墙。状态防火墙通常比非状态防火墙安全得多，因为它允许我们编写更严格的规则集。

The state machine is a special part within iptables that should really not be called the state machine at all, since it is really a connection tracking machine. However, most people recognize it under the first name. Throughout this chapter I will use these names more or less as if they were synonymous. This should not be overly confusing. Connection tracking is done to let the Netfilter framework know the state of a specific connection. Firewalls that implement this are generally called stateful firewalls. A stateful firewall is generally much more secure than non-stateful firewalls since it allows us to write much tighter rule-sets.

在 iptables 中，数据包可以与四种不同的所谓状态下的跟踪连接相关。这些被称为新的、已建立的、相关的和无效的。稍后我们将更深入地讨论其中的每一个。通过 --state 匹配，我们可以轻松控制允许谁或什么发起新会话。

Within iptables, packets can be related to tracked connections in four different so called states. These are known as NEW, ESTABLISHED, RELATED and INVALID. We will discuss each of these in more depth later. With the --state match we can easily control who or what is allowed to initiate new sessions.

所有连接跟踪都是由内核中称为 conntrack 的特殊框架完成的。conntrack 可以作为模块加载，也可以作为内核本身的内部部分加载。大多数时候，我们需要并且想要比默认 conntrack 引擎可以维护的更具体的连接跟踪。因此，conntrack 也有更具体的部分来处理 TCP、UDP 或 ICMP 协议等。这些模块从数据包中获取特定的、唯一的信息，以便它们可以跟踪每个数据流。然后，conntrack 收集的信息用于告诉 conntrack 流当前处于哪种状态。例如，UDP 流通常由其目标 IP 地址、源 IP 地址、目标端口和源端口唯一标识。

All of the connection tracking is done by special framework within the kernel called conntrack. conntrack may be loaded either as a module, or as an internal part of the kernel itself. Most of the time, we need and want more specific connection tracking than the default conntrack engine can maintain. Because of this, there are also more specific parts of conntrack that handles the TCP, UDP or ICMP protocols among others. These modules grab specific, unique, information from the packets, so that they may keep track of each stream of data. The information that conntrack gathers is then used to tell conntrack in which state the stream is currently in. For example, UDP streams are, generally, uniquely identified by their destination IP address, source IP address, destination port and source port.

在以前的内核中，我们可以打开和关闭碎片整理。然而，自从引入了 iptables 和 Netfilter，特别是连接跟踪后，这个选项就被去掉了。原因是如果不进行数据包碎片整理，连接跟踪就无法正常工作，因此碎片整理已合并到 conntrack 中并自动执行。除非关闭连接跟踪，否则无法将其关闭。如果打开连接跟踪，则始终执行碎片整理。

In previous kernels, we had the possibility to turn on and off defragmentation. However, since iptables and Netfilter were introduced and connection tracking in particular, this option was gotten rid of. The reason for this is that connection tracking can not work properly without defragmenting packets, and hence defragmenting has been incorporated into conntrack and is carried out automatically. It can not be turned off, except by turning off connection tracking. Defragmentation is always carried out if connection tracking is turned on.

所有连接跟踪均在 PREROUTING 链中处理，本地生成的数据包除外，这些数据包在 OUTPUT 链中处理。这意味着 iptables 将在 PREROUTING 链内重新计算所有状态等。如果我们在流中发送初始数据包，则 OUTPUT 链中的状态将设置为 NEW，当我们收到返回数据包时，PREROUTING 链中的状态将更改为 ESTABLISHED，依此类推。如果第一个数据包不是我们自己发起的，当然会在 PREROUTING 链中设置 NEW 状态。因此，所有状态更改和计算都是在 nat 表的 PREROUTING 和 OUTPUT 链内完成的。

All connection tracking is handled in the PREROUTING chain, except locally generated packets which are handled in the OUTPUT chain. What this means is that iptables will do all recalculation of states and so on within the PREROUTING chain. If we send the initial packet in a stream, the state gets set to NEW within the OUTPUT chain, and when we receive a return packet, the state gets changed in the PREROUTING chain to ESTABLISHED, and so on. If the first packet is not originated by ourself, the NEW state is set within the PREROUTING chain of course. So, all state changes and calculations are done within the PREROUTING and OUTPUT chains of the nat table.

conntrack 条目

The conntrack entries

让我们简单看一下 conntrack 条目以及如何在 /proc/net/ip_conntrack中读取它们。这给出了 conntrack 数据库中所有当前条目的列表。如果加载了 ip_conntrack 模块， /proc/net/ip_conntrack的 cat可能如下所示：

Let's take a brief look at a conntrack entry and how to read them in /proc/net/ip_conntrack. This gives a list of all the current entries in your conntrack database. If you have the ip_conntrack module loaded, a cat of /proc/net/ip_conntrack might look like:

tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
     dport=22 [未回复] src=192.168.1.9 dst=192.168.1.6 sport=22 \
     dport=32775 [确定] use=2
     

tcp      6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
     dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
     dport=32775 [ASSURED] use=2
     

此示例包含 conntrack 模块维护的所有信息，以了解特定连接处于哪种状态。首先，我们有一个协议，在本例中为 tcp。接下来，是正常十进制编码中的相同值。之后，我们看看这个 conntrack 条目必须存活多长时间。该值目前设置为 117 秒，并定期递减，直到我们看到更多流量。然后，该值将重置为其在相关时间点所处的特定状态的默认值。接下来是该条目在当前时间点所处的实际状态。在上述情况下，我们正在查看处于 SYN_SENT 状态的数据包。连接的内部值与 iptables 外部使用的值略有不同。SYN_SENT 值告诉我们，我们正在查看一个仅在一个方向上看到 TCP SYN 数据包的连接。接下来，我们看到源IP地址、目标IP地址、源端口和目标端口。此时，我们看到一个特定的关键字，它告诉我们没有看到此连接的返回流量。最后，我们看看我们对返回数据包的期望。该信息详细说明了源 IP 地址和目标 IP 地址（两者都是颠倒的，因为数据包将被定向回我们）。连接的源端口和目标端口也是如此。这些是我们应该感兴趣的价值观。此时，我们看到一个特定的关键字，它告诉我们没有看到此连接的返回流量。最后，我们看看我们对返回数据包的期望。该信息详细说明了源 IP 地址和目标 IP 地址（两者都是颠倒的，因为数据包将被定向回我们）。连接的源端口和目标端口也是如此。这些是我们应该感兴趣的价值观。此时，我们看到一个特定的关键字，它告诉我们没有看到此连接的返回流量。最后，我们看看我们对返回数据包的期望。该信息详细说明了源 IP 地址和目标 IP 地址（两者都是颠倒的，因为数据包将被定向回我们）。连接的源端口和目标端口也是如此。这些是我们应该感兴趣的价值观。

This example contains all the information that the conntrack module maintains to know which state a specific connection is in. First of all, we have a protocol, which in this case is tcp. Next, the same value in normal decimal coding. After this, we see how long this conntrack entry has to live. This value is set to 117 seconds right now and is decremented regularly until we see more traffic. This value is then reset to the default value for the specific state that it is in at that relevant point of time. Next comes the actual state that this entry is in at the present point of time. In the above mentioned case we are looking at a packet that is in the SYN_SENT state. The internal value of a connection is slightly different from the ones used externally with iptables. The value SYN_SENT tells us that we are looking at a connection that has only seen a TCP SYN packet in one direction. Next, we see the source IP address, destination IP address, source port and destination port. At this point we see a specific keyword that tells us that we have seen no return traffic for this connection. Lastly, we see what we expect of return packets. The information details the source IP address and destination IP address (which are both inverted, since the packet is to be directed back to us). The same thing goes for the source port and destination port of the connection. These are the values that should be of any interest to us.

连接跟踪条目可能采用一系列不同的值，所有这些值都在 linux/include/netfilter-ipv4/ip_conntrack*.h文件中可用的 conntrack 标头中指定。这些值取决于我们使用的 IP 子协议。TCP、UDP 或 ICMP 协议采用linux/include/netfilter-ipv4/ip_conntrack.h中指定的特定默认值 。当我们查看每个协议时，我们会更仔细地了解这一点；然而，我们不会在本章中广泛使用它们，因为它们不会在 conntrack 内部之外使用。另外，根据状态的变化，连接被破坏之前的默认时间值也会发生变化。

The connection tracking entries may take on a series of different values, all specified in the conntrack headers available in linux/include/netfilter-ipv4/ip_conntrack*.h files. These values are dependent on which sub-protocol of IP we use. TCP, UDP or ICMP protocols take specific default values as specified in linux/include/netfilter-ipv4/ip_conntrack.h. We will look closer at this when we look at each of the protocols; however, we will not use them extensively through this chapter, since they are not used outside of the conntrack internals. Also, depending on how this state changes, the default value of the time until the connection is destroyed will also change.

最近，iptables patch-o-matic 中提供了一个新补丁，称为 tcp-window-tracking。该补丁将上述所有超时添加到特殊的 sysctl 变量中，这意味着它们可以在系统仍在运行时动态更改。因此，这使得每次想要更改超时时都无需重新编译内核。 Recently there was a new patch made available in iptables patch-o-matic, called tcp-window-tracking. This patch adds, among other things, all of the above timeouts to special sysctl variables, which means that they can be changed on the fly, while the system is still running. Hence, this makes it unnecessary to recompile the kernel every time you want to change the timeouts. 这些可以通过使用/proc/sys/net/ipv4/netfilter目录中可用的特定系统调用来更改 。您应该特别查看 /proc/sys/net/ipv4/netfilter/ip_ct_*变量。 These can be altered via using specific system calls available in the /proc/sys/net/ipv4/netfilter directory. You should in particular look at the /proc/sys/net/ipv4/netfilter/ip_ct_* variables.

当连接看到两个方向的流量时，conntrack 条目将擦除 [UNREPLIED] 标志，然后重置它。告诉我们连接没有看到任何双向流量的条目将被 [ASSURED] 标志替换，可以在条目末尾附近找到。[ASSURED] 标志告诉我们这个连接是有保证的，并且如果我们达到最大可能的跟踪连接，它不会被删除。因此，与非保证连接（未标记为 [ASSURED] 的连接）相反，标记为 [ASSURED] 的连接不会被删除。连接跟踪表可以容纳多少个连接取决于可以通过最新内核中的 ip-sysctl 函数设置的变量。该条目保存的默认值在很大程度上取决于您拥有的内存量。在 128 MB RAM 上，您将获得 8192 个可能的条目，在 256 MB RAM 上，您将获得 16376 个条目。您可以通过以下方式读取和设置您的设置 /proc/sys/net/ipv4/ip_conntrack_max设置。

When a connection has seen traffic in both directions, the conntrack entry will erase the [UNREPLIED] flag, and then reset it. The entry that tells us that the connection has not seen any traffic in both directions, will be replaced by the [ASSURED] flag, to be found close to the end of the entry. The [ASSURED] flag tells us that this connection is assured and that it will not be erased if we reach the maximum possible tracked connections. Thus, connections marked as [ASSURED] will not be erased, contrary to the non-assured connections (those not marked as [ASSURED]). How many connections that the connection tracking table can hold depends upon a variable that can be set through the ip-sysctl functions in recent kernels. The default value held by this entry varies heavily depending on how much memory you have. On 128 MB of RAM you will get 8192 possible entries, and at 256 MB of RAM, you will get 16376 entries. You can read and set your settings through the /proc/sys/net/ipv4/ip_conntrack_max setting.

另一种更有效的方法是在加载ip_conntrack模块后将 hashsize 选项设置为该模块。正常情况下ip_conntrack_max等于8 * hashsize。换句话说，将 hashsize 设置为 4096 将导致 ip_conntrack_max 设置为 32768 个 conntrack 条目。一个例子是：

A different way of doing this, that is more efficient, is to set the hashsize option to the ip_conntrack module once this is loaded. Under normal circumstances ip_conntrack_max equals 8 * hashsize. In other words, setting the hashsize to 4096 will result in ip_conntrack_max being set to 32768 conntrack entries. An example of this would be:

工作3:/home/blueflux# modprobe ip_conntrack hashsize=4096
工作3:/home/blueflux# cat /proc/sys/net/ipv4/ip_conntrack_max
32768
工作3:/home/blueflux#
      

work3:/home/blueflux# modprobe ip_conntrack hashsize=4096
work3:/home/blueflux# cat /proc/sys/net/ipv4/ip_conntrack_max
32768
work3:/home/blueflux#
      

用户态状态

User-land states

正如您所看到的，数据包在内核本身内可能呈现几种不同的状态，具体取决于我们正在讨论的协议。然而，在内核之外，我们只有前面描述的 4 种状态。这些状态主要可以与状态匹配结合使用，然后状态匹配将能够根据数据包当前的连接跟踪状态来匹配数据包。有效状态为 NEW、ESTABLISHED、RELATED 和 INVALID。下表将简要解释每种可能的状态。

As you have seen, packets may take on several different states within the kernel itself, depending on what protocol we are talking about. However, outside the kernel, we only have the 4 states as described previously. These states can mainly be used in conjunction with the state match which will then be able to match packets based on their current connection tracking state. The valid states are NEW, ESTABLISHED, RELATED and INVALID. The following table will briefly explain each possible state.

这些状态可以与 --state 匹配一起使用，以根据数据包的连接跟踪状态来匹配数据包。这就是状态机对于我们的防火墙来说如此强大和高效的原因。以前，我们经常必须打开 1024 以上的所有端口，才能让所有流量再次返回到我们的本地网络。有了状态机，就不再需要这样做了，因为我们现在只需为返回流量打开防火墙，而不是为所有其他流量打开防火墙。

These states can be used together with the --state match to match packets based on their connection tracking state. This is what makes the state machine so incredibly strong and efficient for our firewall. Previously, we often had to open up all ports above 1024 to let all traffic back into our local networks again. With the state machine in place this is not necessary any longer, since we can now just open up the firewall for return traffic and not for all kinds of other traffic.

TCP 连接数

TCP connections

在本节和接下来的章节中，我们将仔细研究 TCP、UDP 和 ICMP 三种基本协议的状态以及如何处理它们。此外，如果连接不能归类为这三种协议中的任何一种，我们将仔细研究默认情况下如何处理连接。我们选择从 TCP 协议开始，因为它本身就是一个有状态的协议，并且有很多关于 iptables 中的状态机的有趣细节。

In this section and the upcoming ones, we will take a closer look at the states and how they are handled for each of the three basic protocols TCP, UDP and ICMP. Also, we will take a closer look at how connections are handled per default, if they can not be classified as either of these three protocols. We have chosen to start out with the TCP protocol since it is a stateful protocol in itself, and has a lot of interesting details with regard to the state machine in iptables.

TCP 连接始终通过 3 次握手来启动，这会建立并协商发送数据的实际连接。整个会话以 SYN 数据包开始，然后是 SYN/ACK 数据包，最后是 ACK 数据包以确认整个会话的建立。此时连接已建立并可以开始发送数据。最大的问题是，连接跟踪如何与此挂钩？真的很简单。

A TCP connection is always initiated with the 3-way handshake, which establishes and negotiates the actual connection over which data will be sent. The whole session is begun with a SYN packet, then a SYN/ACK packet and finally an ACK packet to acknowledge the whole session establishment. At this point the connection is established and able to start sending data. The big problem is, how does connection tracking hook up into this? Quite simply really.

就用户而言，连接跟踪对于所有连接类型的工作原理基本相同。查看下图，了解流在连接的不同阶段进入的确切状态。正如您所看到的，从用户的角度来看，连接跟踪代码并没有真正遵循 TCP 连接的流程。一旦它看到一个数据包（SYN），它就会认为该连接是新的。一旦它看到返回数据包（SYN/ACK），它就认为连接已建立。如果你想一想，你就会明白为什么。通过这个特定的实现，您可以允许新的和已建立的数据包离开您的本地网络，只允许已建立的连接回来，这将完美地工作。相反，如果连接跟踪机将整个连接建立视为新的，我们永远无法真正阻止外部连接到我们的本地网络，因为我们必须允许新的数据包再次返回。让事情变得更复杂的是，还有许多其他内部状态用于内核内部的 TCP 连接，但在用户态中我们无法使用这些状态。大致上，它们遵循规定的国家标准RFC 793 - 传输控制协议第 21-23 页。我们将在本节中进一步详细讨论这些内容。

As far as the user is concerned, connection tracking works basically the same for all connection types. Have a look at the picture below to see exactly what state the stream enters during the different stages of the connection. As you can see, the connection tracking code does not really follow the flow of the TCP connection, from the users viewpoint. Once it has seen one packet(the SYN), it considers the connection as NEW. Once it sees the return packet(SYN/ACK), it considers the connection as ESTABLISHED. If you think about this a second, you will understand why. With this particular implementation, you can allow NEW and ESTABLISHED packets to leave your local network, only allow ESTABLISHED connections back, and that will work perfectly. Conversely, if the connection tracking machine were to consider the whole connection establishment as NEW, we would never really be able to stop outside connections to our local network, since we would have to allow NEW packets back in again. To make things more complicated, there are a number of other internal states that are used for TCP connections inside the kernel, but which are not available for us in User-land. Roughly, they follow the state standards specified within RFC 793 - Transmission Control Protocol on pages 21-23. We will consider these in more detail further along in this section.

正如您所看到的，从用户的角度来看，这确实非常简单。不过，从内核的角度来看整个构建，就有点困难了。让我们看一个例子。准确考虑/proc/net/ip_conntrack表中的连接状态如何变化 。第一个状态是在连接中收到第一个 SYN 数据包时报告的。

As you can see, it is really quite simple, seen from the user's point of view. However, looking at the whole construction from the kernel's point of view, it's a little more difficult. Let's look at an example. Consider exactly how the connection states change in the /proc/net/ip_conntrack table. The first state is reported upon receipt of the first SYN packet in a connection.

tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [未回复] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 使用=1
   

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1
   

正如您从上面的条目中看到的，我们有一个精确的状态，其中 SYN 数据包已发送（设置了 SYN_SENT 标志），并且尚未发送回复（见证 [UNREPLIED] 标志）。当我们在另一个方向看到另一个数据包时，将达到下一个内部状态。

As you can see from the above entry, we have a precise state in which a SYN packet has been sent, (the SYN_SENT flag is set), and to which as yet no reply has been sent (witness the [UNREPLIED] flag). The next internal state will be reached when we see another packet in the other direction.

tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 运动=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     使用=1
   

tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     use=1
   

现在我们已经收到了相应的 SYN/ACK 作为回报。一旦收到此数据包，状态就会再次更改，这次更改为 SYN_RECV。SYN_RECV 告诉我们原始 SYN 已正确传送，并且 SYN/ACK 返回数据包也已正确通过防火墙。此外，该连接跟踪条目现在已看到两个方向的流量，因此被认为已得到回复。这不是明确的，而是假设的，就像上面的 [UNREPLIED] 标志一样。一旦我们看到 3 次握手中的最终 ACK，就到达了最后一步。

Now we have received a corresponding SYN/ACK in return. As soon as this packet has been received, the state changes once again, this time to SYN_RECV. SYN_RECV tells us that the original SYN was delivered correctly and that the SYN/ACK return packet also got through the firewall properly. Moreover, this connection tracking entry has now seen traffic in both directions and is hence considered as having been replied to. This is not explicit, but rather assumed, as was the [UNREPLIED] flag above. The final step will be reached once we have seen the final ACK in the 3-way handshake.

tcp 6 431999 已建立 src=192.168.1.5 dst=192.168.1.35 \
     运动=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     运动=23 dport=1031 [确定] 使用=1
   

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 [ASSURED] use=1
   

在最后一个示例中，就 iptables 的内部机制而言，我们在 3 次握手中获得了最终的 ACK，并且连接已进入 ESTABLISHED 状态。通常情况下，此时流将得到保证。

In the last example, we have gotten the final ACK in the 3-way handshake and the connection has entered the ESTABLISHED state, as far as the internal mechanisms of iptables are aware. Normally, the stream will be ASSURED by now.

连接也可能进入 ESTABLISHED 状态，但不会进入 [ASSURED]。如果我们打开了连接拾取（需要 tcp-window-tracking 补丁，并且 ip_conntrack_tcp_loose 设置为 1 或更高），就会发生这种情况。默认情况下，如果没有 tcp-window-tracking 补丁，则具有此行为，并且不可更改。

A connection may also enter the ESTABLISHED state, but not be[ASSURED]. This happens if we have connection pickup turned on (Requires the tcp-window-tracking patch, and the ip_conntrack_tcp_loose to be set to 1 or higher). The default, without the tcp-window-tracking patch, is to have this behaviour, and is not changeable.

当 TCP 连接关闭时，会按以下方式完成并采取以下状态。

When a TCP connection is closed down, it is done in the following way and takes the following states.

正如您所看到的，在发送最后一个 ACK​​ 之前，连接永远不会真正关闭。请注意，此图仅描述了正常情况下如何关闭。例如，如果连接被拒绝，则还可以通过发送 RST（重置）来关闭连接。在这种情况下，连接将立即关闭。

As you can see, the connection is never really closed until the last ACK is sent. Do note that this picture only describes how it is closed down under normal circumstances. A connection may also, for example, be closed by sending a RST(reset), if the connection were to be refused. In this case, the connection would be closed down immediately.

当 TCP 连接关闭时，连接进入 TIME_WAIT 状态，默认设置为 2 分钟。这样一来，即使连接已经关闭，所有乱序的数据包仍然可以通过我们的规则集。这被用作一种缓冲时间，以便卡在一个或另一个拥塞路由器中的数据包仍然可以到达防火墙或连接的另一端。

When the TCP connection has been closed down, the connection enters the TIME_WAIT state, which is per default set to 2 minutes. This is used so that all packets that have gotten out of order can still get through our rule-set, even after the connection has already closed. This is used as a kind of buffer time so that packets that have gotten stuck in one or another congested router can still get to the firewall, or to the other end of the connection.

如果连接被 RST 数据包重置，则状态更改为 CLOSE。这意味着在整个连接被明确关闭之前，默认连接有 10 秒的时间。RST 数据包在任何意义上都不会被确认，并且会直接断开连接。除了我们到目前为止所介绍的状态之外，还有其他状态。以下是 TCP 流可能采取的可能状态及其超时值的完整列表。

If the connection is reset by a RST packet, the state is changed to CLOSE. This means that the connection per default has 10 seconds before the whole connection is definitely closed down. RST packets are not acknowledged in any sense, and will break the connection directly. There are also other states than the ones we have told you about so far. Here is the complete list of possible states that a TCP stream may take, and their timeout values.

这些值绝对不是绝对的。它们可能会随着内核修订而变化，也可能通过/proc/sys/net/ipv4/netfilter/ip_ct_tcp_*变量中的 proc 文件系统进行更改 。然而，默认值应该在实践中得到很好的确立。这些值以秒为单位设置。该补丁的早期版本使用 jiffies（这是一个错误）。

These values are most definitely not absolute. They may change with kernel revisions, and they may also be changed via the proc file-system in the /proc/sys/net/ipv4/netfilter/ip_ct_tcp_* variables. The default values should, however, be fairly well established in practice. These values are set in seconds. Early versions of the patch used jiffies (which was a bug).

另请注意，状态机的用户态端不会查看 TCP 数据包中设置的 TCP 标志（即 RST、ACK 和 SYN 是标志）。这通常是不好的，因为您可能希望允许处于 NEW 状态的数据包通过防火墙，但是当您指定 NEW 标志时，在大多数情况下您将意味着 SYN 数据包。 Also note that the User-land side of the state machine does not look at TCP flags (i.e., RST, ACK, and SYN are flags) set in the TCP packets. This is generally bad, since you may want to allow packets in the NEW state to get through the firewall, but when you specify the NEW flag, you will in most cases mean SYN packets. 这不是当前状态实施中发生的情况；相反，即使没有设置位或 ACK 标志的数据包也将被视为新数据包。这可以用于冗余防火墙等，但在只有一个防火墙的家庭网络上通常非常糟糕。要解决此问题，您可以使用常见问题和问题附录的“状态新数据包但没有 SYN 位设置”部分中解释的命令。另一种方法是从 patch-o-matic 安装 tcp-window-tracking 扩展，并将/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose设置 为零，这将使防火墙丢弃除SYN 标志已设置。 This is not what happens with the current state implementation; instead, even a packet with no bit set or an ACK flag, will count as NEW. This can be used for redundant firewalling and so on, but it is generally extremely bad on your home network, where you only have a single firewall. To get around this behavior, you could use the command explained in the State NEW packets but no SYN bit set section of the Common problems and questions appendix. Another way is to install the tcp-window-tracking extension from patch-o-matic, and set the /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose to zero, which will make the firewall drop all NEW packets with anything but the SYN flag set.

UDP 连接

UDP connections

UDP 连接本身不是有状态连接，而是无状态的。原因有几个，主要是因为它们不包含任何连接建立或连接关闭；最重要的是，它们缺乏排序。按特定顺序接收两个 UDP 数据报并不会说明它们的发送顺序。然而，仍然可以在内核内设置连接的状态。让我们看一下如何跟踪连接以及它在 conntrack 中的外观。

UDP connections are in themselves not stateful connections, but rather stateless. There are several reasons why, mainly because they don't contain any connection establishment or connection closing; most of all they lack sequencing. Receiving two UDP datagrams in a specific order does not say anything about the order in which they were sent. It is, however, still possible to set states on the connections within the kernel. Let's have a look at how a connection can be tracked and how it might look in conntrack.

正如您所看到的，连接的建立方式几乎与 TCP 连接完全相同。也就是说，从用户域的角度来看。从内部来看，conntrack 信息看起来有点不同，但本质上细节是相同的。首先，让我们看一下初始 UDP 数据包发送后的条目。

As you can see, the connection is brought up almost exactly in the same way as a TCP connection. That is, from the user-land point of view. Internally, conntrack information looks quite a bit different, but intrinsically the details are the same. First of all, let's have a look at the entry after the initial UDP packet has been sent.

udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
     [未回复] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 使用=1
   

udp      17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
     [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1
   

从第一个和第二个值可以看出，这是一个 UDP 数据包。第一个是协议名称，第二个是协议编号。这与 TCP 连接相同。第三个值标记此状态条目必须存活多少秒。之后，我们获得我们所看到的数据包的值以及通过该连接从发起数据包发送者到达我们的数据包的未来期望。它们是源、目标、源端口和目标端口。此时，[UNREPLIED] 标志告诉我们到目前为止还没有对该数据包的响应。最后，我们得到了返回数据包的期望的简短列表。请注意，后面的条目与第一个值的顺序相反。默认情况下，此时超时设置为 30 秒。

As you can see from the first and second values, this is an UDP packet. The first is the protocol name, and the second is protocol number. This is just the same as for TCP connections. The third value marks how many seconds this state entry has to live. After this, we get the values of the packet that we have seen and the future expectations of packets over this connection reaching us from the initiating packet sender. These are the source, destination, source port and destination port. At this point, the [UNREPLIED] flag tells us that there's so far been no response to the packet. Finally, we get a brief list of the expectations for returning packets. Do note that the latter entries are in reverse order to the first values. The timeout at this point is set to 30 seconds, as per default.

udp 17 170 src=192.168.1.2 dst=192.168.1.5 运动=137 \
     dport=1025 src=192.168.1.5 dst=192.168.1.2 运动=1025 \
     dport=137 [确定] use=1
   

udp      17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
     dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 [ASSURED] use=1
   

此时，服务器已看到对发出的第一个数据包的回复，并且连接现在被视为已建立。正如您所看到的，这没有显示在连接跟踪中。主要区别在于 [UNREPLIED] 标志现已消失。此外，默认超时已更改为 180 秒 - 但在此示例中，该超时现已减少为 170 秒 - 10 秒后，它将变为 160 秒。不过，缺少一件事，并且可以稍微改变一下，那就是上面描述的 [ASSURED] 标志。为了在跟踪的连接上设置 [ASSURED] 标志，必须有一个对 NEW 数据包的合法回复数据包。

At this point the server has seen a reply to the first packet sent out and the connection is now considered as ESTABLISHED. This is not shown in the connection tracking, as you can see. The main difference is that the [UNREPLIED] flag has now gone. Moreover, the default timeout has changed to 180 seconds - but in this example that's by now been decremented to 170 seconds - in 10 seconds' time, it will be 160 seconds. There's one thing that's missing, though, and can change a bit, and that is the [ASSURED] flag described above. For the [ASSURED] flag to be set on a tracked connection, there must have been a legitimate reply packet to the NEW packet.

udp 17 175 src=192.168.1.5 dst=195.22.79.2 运动=1025 \
     dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
     dport=1025 [确定] use=1
   

udp      17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
     dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
     dport=1025 [ASSURED] use=1
   

至此，连接已确定。连接看起来与前面的示例完全相同。如果此连接在 180 秒内未使用，则会超时。180 秒是一个相对较低的值，但对于大多数使用来说应该足够了。对于匹配相同条目并通过防火墙的每个数据包，该值将重置为其完整值，与所有内部状态相同。

At this point, the connection has become assured. The connection looks exactly the same as the previous example. If this connection is not used for 180 seconds, it times out. 180 Seconds is a comparatively low value, but should be sufficient for most use. This value is reset to its full value for each packet that matches the same entry and passes through the firewall, just the same as for all of the internal states.

ICMP 连接

ICMP connections

ICMP 数据包远非有状态流，因为它们仅用于控制并且永远不应该建立任何连接。然而，有四种 ICMP 类型会生成返回数据包，并且它们有 2 种不同的状态。这些 ICMP 消息可以采用 NEW 和 ESTABLISHED 状态。我们讨论的 ICMP 类型是 Echo 请求和回复、时间戳请求和回复、信息请求和回复以及最后的地址掩码请求和回复。其中，时间戳请求和信息请求已过时，很可能会被删除。但是，Echo 消息可用于多种设置，例如 ping 主机。地址掩码请求不经常使用，但有时可能很有用并且值得允许。要了解其外观，请查看下图。

ICMP packets are far from a stateful stream, since they are only used for controlling and should never establish any connections. There are four ICMP types that will generate return packets however, and these have 2 different states. These ICMP messages can take the NEW and ESTABLISHED states. The ICMP types we are talking about are Echo request and reply, Timestamp request and reply, Information request and reply and finally Address mask request and reply. Out of these, the timestamp request and information request are obsolete and could most probably just be dropped. However, the Echo messages are used in several setups such as pinging hosts. Address mask requests are not used often, but could be useful at times and worth allowing. To get an idea of how this could look, have a look at the following image.

如上图所示，主机向目标发送回显请求，防火墙将其视为 NEW。然后，目标以回显答复进行响应，防火墙将其视为状态已建立。当看到第一个 echo 请求时，以下状态条目将进入ip_conntrack。

As you can see in the above picture, the host sends an echo request to the target, which is considered as NEW by the firewall. The target then responds with a echo reply which the firewall considers as state ESTABLISHED. When the first echo request has been seen, the following state entry goes into the ip_conntrack.

icmp 1 25 src=192.168.1.6 dst=192.168.1.10 类型=8 代码=0 \
     id=33029 [未回复] src=192.168.1.10 dst=192.168.1.6 \
     类型=0 代码=0 id=33029 使用=1
   

icmp     1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
     id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
     type=0 code=0 id=33029 use=1
   

如您所见，此条目看起来与 TCP 和 UDP 的标准状态有点不同。协议、超时以及源地址和目标地址都在那里。然而问题在那之后就来了。我们现在有 3 个新字段，称为类型、代码和 ID。它们在任何方面都没有特殊之处，类型字段包含 ICMP 类型，代码字段包含 ICMP 代码。这些都可以在ICMP 类型附录中找到。最后的 id 字段包含 ICMP ID。每个 ICMP 数据包在发送时都会设置一个 ID，当接收方收到 ICMP 消息时，它会在新的 ICMP 消息中设置相同的 ID，以便发送方能够识别回复并能够将其与发送方连接起来。正确的 ICMP 请求。

This entry looks a little bit different from the standard states for TCP and UDP as you can see. The protocol is there, and the timeout, as well as source and destination addresses. The problem comes after that however. We now have 3 new fields called type, code and id. They are not special in any way, the type field contains the ICMP type and the code field contains the ICMP code. These are all available in ICMP types appendix. The final id field, contains the ICMP ID. Each ICMP packet gets an ID set to it when it is sent, and when the receiver gets the ICMP message, it sets the same ID within the new ICMP message so that the sender will recognize the reply and will be able to connect it with the correct ICMP request.

下一个字段，我们再次识别为 [UNREPLIED] 标志，我们之前已经见过。与之前一样，此标志告诉我们当前正在查看仅在一个方向上看到流量的连接跟踪条目。最后，我们看到回复 ICMP 数据包的回复期望，它是原始源 IP 地址和目标 IP 地址的反转。至于类型和代码，这些都被更改为返回数据包的正确值，因此回显请求更改为回显应答等。ICMP ID 是从请求数据包中保留的。

The next field, we once again recognize as the [UNREPLIED] flag, which we have seen before. Just as before, this flag tells us that we are currently looking at a connection tracking entry that has seen only traffic in one direction. Finally, we see the reply expectation for the reply ICMP packet, which is the inversion of the original source and destination IP addresses. As for the type and code, these are changed to the correct values for the return packet, so an echo request is changed to echo reply and so on. The ICMP ID is preserved from the request packet.

正如我们已经解释过的，回复数据包被视为已建立。然而，我们可以肯定的是，在ICMP回复之后，同一个连接中绝对不会再有合法的流量。因此，一旦回复完全通过 Netfilter 结构，连接跟踪条目就会被销毁。

The reply packet is considered as being ESTABLISHED, as we have already explained. However, we can know for sure that after the ICMP reply, there will be absolutely no more legal traffic in the same connection. For this reason, the connection tracking entry is destroyed once the reply has traveled all the way through the Netfilter structure.

在上述每种情况下，请求都被视为 NEW，而回复则被视为 ESTABLISHED。让我们更仔细地考虑一下这一点。当防火墙看到请求数据包时，它会将其视为新数据包。当主机发送对请求的答复数据包时，它被视为已建立。

In each of the above cases, the request is considered as NEW, while the reply is considered as ESTABLISHED. Let's consider this more closely. When the firewall sees a request packet, it considers it as NEW. When the host sends a reply packet to the request it is considered ESTABLISHED.

请注意，这意味着回复数据包必须符合连接跟踪条目给出的标准才能被视为已建立，就像所有其他流量类型一样。 Note that this means that the reply packet must match the criterion given by the connection tracking entry to be considered as established, just as with all other traffic types.

ICMP 请求的默认超时为 30 秒，您可以在 /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout条目中更改该超时。一般来说，这应该是一个很好的超时值，因为它将能够捕获大多数传输中的数据包。

ICMP requests has a default timeout of 30 seconds, which you can change in the /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout entry. This should in general be a good timeout value, since it will be able to catch most packets in transit.

ICMP 的另一个非常重要的部分是它用于告诉主机特定 UDP 和 TCP 连接或连接尝试发生了什么。由于这个简单的原因，ICMP 回复通常会被认为与原始连接或连接尝试相关。一个简单的示例是 ICMP 主机无法访问或 ICMP 网络无法访问。如果我们的主机尝试与其他主机建立不成功的连接，则这些应该始终生成回我们的主机，但相关网络或主机可能已关闭，因此尝试到达相关站点的最后一个路由器将回复一条 ICMP 消息，告知我们关于它。在这种情况下，ICMP 回复被视为 RELATED 数据包。下图应该解释它的外观。

Another hugely important part of ICMP is the fact that it is used to tell the hosts what happened to specific UDP and TCP connections or connection attempts. For this simple reason, ICMP replies will very often be recognized as RELATED to original connections or connection attempts. A simple example would be the ICMP Host unreachable or ICMP Network unreachable. These should always be spawned back to our host if it attempts an unsuccessful connection to some other host, but the network or host in question could be down, and hence the last router trying to reach the site in question will reply with an ICMP message telling us about it. In this case, the ICMP reply is considered as a RELATED packet. The following picture should explain how it would look.

在上面的示例中，我们向特定地址发送 SYN 数据包。防火墙将其视为新连接。然而，数据包试图到达的网络无法到达，因此路由器向我们返回网络不可达 ICMP 错误。连接跟踪代码可以将此数据包识别为“相关”。由于已经添加了跟踪条目，因此 ICMP 回复已正确发送到客户端，然后有望中止。同时，防火墙已销毁连接跟踪条目，因为它知道这是一条错误消息。

In the above example, we send out a SYN packet to a specific address. This is considered as a NEW connection by the firewall. However, the network the packet is trying to reach is unreachable, so a router returns a network unreachable ICMP error to us. The connection tracking code can recognize this packet as RELATED. thanks to the already added tracking entry, so the ICMP reply is correctly sent to the client which will then hopefully abort. Meanwhile, the firewall has destroyed the connection tracking entry since it knows this was an error message.

如果 UDP 连接遇到上述任何问题，则会出现与上述相同的行为。所有为回复 UDP 连接而发送的 ICMP 消息都被视为相关的。考虑下图。

The same behavior as above is experienced with UDP connections if they run into any problem like the above. All ICMP messages sent in reply to UDP connections are considered as RELATED. Consider the following image.

这次UDP数据包被发送到主机。该 UDP 连接被视为新连接。然而，网络在传输过程中被某些防火墙或路由器在管理上禁止。因此，我们的防火墙会收到 ICMP 网络禁止作为回报。防火墙知道此 ICMP 错误消息与已打开的 UDP 连接相关，并将其作为 RELATED 数据包发送到客户端。此时，防火墙会破坏连接跟踪条目，客户端收到 ICMP 消息，应该会中止。

This time an UDP packet is sent to the host. This UDP connection is considered as NEW. However, the network is administratively prohibited by some firewall or router on the way over. Hence, our firewall receives a ICMP Network Prohibited in return. The firewall knows that this ICMP error message is related to the already opened UDP connection and sends it as a RELATED packet to the client. At this point, the firewall destroys the connection tracking entry, and the client receives the ICMP message and should hopefully abort.

默认连接

Default connections

在某些情况下，conntrack 机器不知道如何处理特定协议。如果它不了解该协议，或者不知道它是如何工作的，就会发生这种情况。在这些情况下，它会返回到默认行为。默认行为用于 NETBLT、MUX 和 EGP 等。此行为看起来与 UDP 连接跟踪非常相似。第一个数据包被视为“新”，而回复流量等被视为“已建立”。

In certain cases, the conntrack machine does not know how to handle a specific protocol. This happens if it does not know about that protocol in particular, or doesn't know how it works. In these cases, it goes back to a default behavior. The default behavior is used on, for example, NETBLT, MUX and EGP. This behavior looks pretty much the same as the UDP connection tracking. The first packet is considered NEW, and reply traffic and so forth is considered ESTABLISHED.

当使用默认行为时，所有这些数据包将获得相同的默认超时值。这可以通过/proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout变量设置 。此处的默认值为 600 秒，即 10 分钟。根据您尝试通过使用默认连接跟踪行为的链接发送的流量，这可能需要更改。特别是如果您通过卫星等来传输流量，这可能需要很长时间。

When the default behavior is used, all of these packets will attain the same default timeout value. This can be set via the /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout variable. The default value here is 600 seconds, or 10 minutes. Depending on what traffic you are trying to send over a link that uses the default connection tracking behavior, this might need changing. Especially if you are bouncing traffic through satellites and such, which can take a long time.

未跟踪的连接和原始表

Untracked connections and the raw table

当涉及到 Linux 中的连接跟踪时，UNTRACKED 是一个相当特殊的关键字。基本上，它用于匹配原始表中已标记为不被跟踪的数据包。

UNTRACKED is a rather special keyword when it comes to connection tracking in Linux. Basically, it is used to match packets that has been marked in the raw table not to be tracked.

原始表是专门为此创建的。在此表中，您可以在不希望在 netfilter 中跟踪的数据包上设置 NOTRACK 标记。

The raw table was created specifically for this reason. In this table, you set a NOTRACK mark on packets that you do not wish to track in netfilter.

请注意我如何说数据包，而不是连接，因为标记实际上是为每个进入的数据包设置的。否则，我们仍然需要对连接进行某种类型的跟踪才能知道它不应该被跟踪。 Notice how I say packets, not connection, since the mark is actually set for each and every packet that enters. Otherwise, we would still have to do some kind of tracking of the connection to know that it should not be tracked.

正如我们在本章中已经说过的，conntrack 和状态机相当消耗资源。因此，有时关闭连接跟踪和状态机可能是个好主意。

As we have already stated in this chapter, conntrack and the state machine is rather resource hungry. For this reason, it might sometimes be a good idea to turn off connection tracking and the state machine.

一个例子是，如果您有一台流量很大的路由器，您希望在其上对传入和传出流量进行防火墙设置，但不对路由流量进行防火墙设置。然后，您可以通过在原始表中接受所有以您的主机为目的地的数据包，在所有未发往防火墙本身的数据包上设置 NOTRACK 标记，然后为所有其他流量设置 NOTRACK。这将允许您对路由器本身的传入流量进行状态匹配，但同时由于不处理所有交叉流量而节省了处理能力。

One example would be if you have a heavily trafficked router that you want to firewall the incoming and outgoing traffic on, but not the routed traffic. You could then set the NOTRACK mark on all packets not destined for the firewall itself by ACCEPT'ing all packets with destination your host in the raw table, and then set the NOTRACK for all other traffic. This would then allow you to have stateful matching on incoming traffic for the router itself, but at the same time save processing power from not handling all the crossing traffic.

可以使用 NOTRACK 的另一个例子是，如果您有一个流量很大的网络服务器，并且想要进行状态跟踪，但又不想在跟踪网络流量上浪费处理能力。然后，您可以设置一条规则，对所有本地拥有的 IP 地址或实际提供 Web 流量的 IP 地址上的端口 80 进行跟踪。然后，您可以享受对所有其他服务的全状态跟踪，但网络流量除外，这可能会在已经过载的系统上节省一些处理能力。

Another example when NOTRACK can be used is if you have a highly trafficked webserver and want to do stateful tracking, but don't want to waste processing power on tracking the web traffic. You could then set up a rule that turns of tracking for port 80 on all the locally owned IP addresses, or the ones that are actually serving web traffic. You could then enjoy statefull tracking on all other services, except for webtraffic which might save some processing power on an already overloaded system.

然而，NOTRACK 存在一些您必须考虑的问题。如果使用 NOTRACK 设置整个连接，那么您也将无法跟踪相关连接，conntrack 和 nat 帮助程序将无法用于未跟踪的连接，相关的 ICMP 错误也不起作用。换句话说，您必须手动打开这些。当涉及 FTP 和 SCTP 等复杂协议时，这可能很难管理。只要您意识到这一点，您就应该能够处理这个问题。

There is however some problems with NOTRACK that you must take into consideration. If a whole connection is set with NOTRACK, then you will not be able to track related connections either, conntrack and nat helpers will simply not work for untracked connections, nor will related ICMP errors do. You will have to open up for these manually in other words. When it comes to complex protocols such as FTP and SCTP et cetera, this can be very hard to manage. As long as you are aware of this, you should be able to handle this however.

复杂的协议和连接跟踪

Complex protocols and connection tracking

某些协议比其他协议更复杂。当涉及到连接跟踪时，这意味着此类协议可能更难正确跟踪。ICQ、IRC 和 FTP 协议就是很好的例子。这些协议中的每一种都在数据包的实际数据有效负载中携带信息，因此需要特殊的连接跟踪帮助程序才能使其正常运行。

Certain protocols are more complex than others. What this means when it comes to connection tracking, is that such protocols may be harder to track correctly. Good examples of these are the ICQ, IRC and FTP protocols. Each and every one of these protocols carries information within the actual data payload of the packets, and hence requires special connection tracking helpers to enable it to function correctly.

这是 Linux 内核内部支持的复杂协议的列表，以及它是在哪个内核版本中引入的。

This is a list of the complex protocols that has support inside the linux kernel, and which kernel version it was introduced in.

• 文件传输协议

• FTP

• IRC

• IRC

• TFTP

• TFTP

我们以 FTP 协议作为第一个例子。FTP 协议首先打开一个称为 FTP 控制会话的连接。当我们通过此会话发出命令时，其他端口将打开以携带与该特定命令相关的其余数据。这些连接可以通过主动或被动两种方式完成。当主动建立连接时，FTP 客户端会向服务器发送要连接的端口和 IP 地址。此后，FTP 客户端打开端口，服务器从随机非特权端口 (>1024) 连接到该指定端口，并通过该端口发送数据。

Let's take the FTP protocol as the first example. The FTP protocol first opens up a single connection that is called the FTP control session. When we issue commands through this session, other ports are opened to carry the rest of the data related to that specific command. These connections can be done in two ways, either actively or passively. When a connection is done actively, the FTP client sends the server a port and IP address to connect to. After this, the FTP client opens up the port and the server connects to that specified port from a random unprivileged port (>1024) and sends the data over it.

这里的问题是防火墙不会知道这些额外的连接，因为它们是在协议数据的实际有效负载内协商的。因此，防火墙将无法知道它应该让服务器通过这些特定端口连接到客户端。

The problem here is that the firewall will not know about these extra connections, since they were negotiated within the actual payload of the protocol data. Because of this, the firewall will be unable to know that it should let the server connect to the client over these specific ports.

解决这个问题的方法是在连接跟踪模块中添加一个特殊的帮助程序，该模块将扫描控制连接中的数据以获取特定的语法和信息。当它遇到正确的信息时，它会将该特定信息添加为“相关”，并且由于该“相关”条目，服务器将能够跟踪连接。请考虑下图以了解 FTP 服务器与客户端建立连接时的状态。

The solution to this problem is to add a special helper to the connection tracking module which will scan through the data in the control connection for specific syntaxes and information. When it runs into the correct information, it will add that specific information as RELATED and the server will be able to track the connection, thanks to that RELATED entry. Consider the following picture to understand the states when the FTP server has made the connection back to the client.

被动 FTP 的工作方式相反。FTP 客户端告诉服务器它需要一些特定数据，服务器会回复要连接的 IP 地址和端口。客户端收到此数据后，将从其自己的端口 20（FTP 数据端口）连接到该特定端口，并获取相关数据。如果您的防火墙后面有一个 FTP 服务器，换句话说，除了标准 iptables 模块之外，您还需要此模块，以便 Internet 上的客户端正确连接到 FTP 服务器。如果您对用户的限制非常严格，并且只想让他们访问 Internet 上的 HTTP 和 FTP 服务器并阻止所有其他端口，情况也是如此。考虑下图及其对被动 FTP 的影响。

Passive FTP works the opposite way. The FTP client tells the server that it wants some specific data, upon which the server replies with an IP address to connect to and at what port. The client will, upon receipt of this data, connect to that specific port, from its own port 20(the FTP-data port), and get the data in question. If you have an FTP server behind your firewall, you will in other words require this module in addition to your standard iptables modules to let clients on the Internet connect to the FTP server properly. The same goes if you are extremely restrictive to your users, and only want to let them reach HTTP and FTP servers on the Internet and block all other ports. Consider the following image and its bearing on Passive FTP.

一些 conntrack 助手已经在内核本身中可用。更具体地说，在撰写本文时，FTP 和 IRC 协议已经有 conntrack 帮助程序。如果您在内核本身中找不到所需的 conntrack 帮助程序，则应该查看用户态 iptables 中的 patch-o-matic 树。patch-o-matic 树可能包含更多 conntrack 助手，例如 ntalk 或 H.323 协议。如果它们在 patch-o-matic 树中不可用，您有多种选择。您可以查看 iptables 的 CVS 源（如果它最近已进入该树），或者您可以联系Netfilter-devel 邮件列表并询问它是否可用。如果不是，并且没有添加它的计划，那么您只能使用自己的设备，并且很可能想要阅读Rusty Russell 的《不可靠的 Netfilter 黑客攻击方法》可从其他资源和链接附录链接 。

Some conntrack helpers are already available within the kernel itself. More specifically, the FTP and IRC protocols have conntrack helpers as of writing this. If you can not find the conntrack helpers that you need within the kernel itself, you should have a look at the patch-o-matic tree within user-land iptables. The patch-o-matic tree may contain more conntrack helpers, such as for the ntalk or H.323 protocols. If they are not available in the patch-o-matic tree, you have a number of options. Either you can look at the CVS source of iptables, if it has recently gone into that tree, or you can contact the Netfilter-devel mailing list and ask if it is available. If it is not, and there are no plans for adding it, you are left to your own devices and would most probably want to read the Rusty Russell's Unreliable Netfilter Hacking HOW-TO which is linked from the Other resources and links appendix.

Conntrack 帮助程序可以静态编译到内核中，也可以作为模块编译。如果它们被编译为模块，您可以使用以下命令加载它们

Conntrack helpers may either be statically compiled into the kernel, or as modules. If they are compiled as modules, you can load them with the following command

modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
modprobe ip_conntrack_tftp
modprobe ip_conntrack_amanda
   

modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
modprobe ip_conntrack_tftp
modprobe ip_conntrack_amanda
   

请注意，连接跟踪与 NAT 无关，因此如果您也对连接进行 NAT，则可能需要更多模块。例如，如果您想要进行 NAT 并跟踪 FTP 连接，则还需要 NAT 模块。所有 NAT 助手均以 ip_nat_ 开头并遵循该命名约定；例如，FTP NAT 帮助程序将被命名为 ip_nat_ftp，IRC 模块将被命名为 ip_nat_irc。conntrack 帮助程序遵循相同的命名约定，因此 IRC conntrack 帮助程序将命名为 ip_conntrack_irc，而 FTP conntrack 帮助程序将命名为 ip_conntrack_ftp。

Do note that connection tracking has nothing to do with NAT, and hence you may require more modules if you are NAT'ing connections as well. For example, if you were to want to NAT and track FTP connections, you would need the NAT module as well. All NAT helpers starts with ip_nat_ and follow that naming convention; so for example the FTP NAT helper would be named ip_nat_ftp and the IRC module would be named ip_nat_irc. The conntrack helpers follow the same naming convention, and hence the IRC conntrack helper would be named ip_conntrack_irc, while the FTP conntrack helper would be named ip_conntrack_ftp.

下一步是什么？

What's next?

本章讨论了 netfilter 中的状态机如何工作以及它如何保持不同连接的状态。本章还讨论了它如何向您（最终用户）表示，以及您可以采取哪些措施来改变其行为，以及进行连接跟踪更复杂的不同协议，以及不同的 conntrack 帮助程序如何发挥作用。

This chapter has discussed how the state machine in netfilter works and how it keeps state of different connections. The chapter has also discussed how it is represented toward you, the end user and what you can do to alter its behavior, as well as different protocols that are more complex to do connection tracking on, and how the different conntrack helpers come into the picture.

下一章将讨论如何使用 iptables 应用程序分发的 iptables-save 和 iptables-restore 程序来保存和恢复规则集。这有利有弊，本章将详细讨论。

The next chapter will discuss how to save and restore rulesets using the iptables-save and iptables-restore programs distributed with the iptables applications. This has both pros and cons, and the chapter will discuss it in detail.

速度考虑因素

Speed considerations

使用 iptables-save 和 iptables-restore 命令的最大原因之一是它们将大大加快较大规则集的加载和保存速度。运行包含 iptables 规则的 shell 脚本的主要问题是，脚本中每次调用 iptables 都会首先从 Netfilter 内核空间中提取整个规则集，然后，它将插入或附加规则，或者执行任何更改此特定命令所需的规则集。最后，它会将新的规则集从自己的内存插入到内核空间。使用 shell 脚本，可以为我们想要插入的每条规则完成此操作，并且每次执行此操作时，都需要更多时间来提取和插入规则集。

One of the largest reasons for using the iptables-save and iptables-restore commands is that they will speed up the loading and saving of larger rule-sets considerably. The main problem with running a shell script that contains iptables rules is that each invocation of iptables within the script will first extract the whole rule-set from the Netfilter kernel space, and after this, it will insert or append rules, or do whatever change to the rule-set that is needed by this specific command. Finally, it will insert the new rule-set from its own memory into kernel space. Using a shell script, this is done for each and every rule that we want to insert, and for each time we do this, it takes more time to extract and insert the rule-set.

为了解决这个问题，有iptables-save和restore命令。iptables-save 命令用于将规则集保存到特殊格式的文本文件中，iptables-restore 命令用于将该文本文件再次加载到内核中。这些命令最好的部分是它们将在一个请求中加载和保存规则集。iptables-save 将从内核获取整个规则集并将其保存到一个文件中。iptables-restore 会在每个表的单个移动中将该特定规则集上传到内核。换句话说，对于非常大的规则集，不是将规则集从内核中删除大约 30,000 次，然后再次将其上传到内核那么多次，

To solve this problem, there is the iptables-save and restore commands. The iptables-save command is used to save the rule-set into a specially formatted text-file, and the iptables-restore command is used to load this text-file into kernel again. The best parts of these commands is that they will load and save the rule-set in one single request. iptables-save will grab the whole rule-set from kernel and save it to a file in one single movement. iptables-restore will upload that specific rule-set to kernel in a single movement for each table. In other words, instead of dropping the rule-set out of kernel some 30,000 times, for really large rule-sets, and then upload it to kernel again that many times, we can now save the whole thing into a file in one movement and then upload the whole thing in as little as three movements depending on how many tables you use.

正如您所理解的，如果您正在处理大量需要插入的规则，那么这些工具绝对适合您。然而，它们确实有缺点，我们将在下一节中详细讨论。

As you can understand, these tools are definitely something for you if you are working on a huge set of rules that needs to be inserted. However, they do have drawbacks that we will discuss more in the next section.

恢复的缺点

Drawbacks with restore

您可能已经想知道，iptables-restore 可以处理任何类型的脚本吗？到目前为止，不，它不能，而且很可能永远不能。这是使用 iptables-restore 的主要缺陷，因为您将无法使用这些文件执行大量操作。例如，如果您的连接具有动态分配的 IP 地址，并且您希望在每次计算机启动时获取此动态 IP，然后在脚本中使用该值，该怎么办？使用 iptables-restore，这或多或少是不可能的。

As you may have already wondered, can iptables-restore handle any kind of scripting? So far, no, it cannot and it will most probably never be able to. This is the main flaw in using iptables-restore since you will not be able to do a huge set of things with these files. For example, what if you have a connection that has a dynamically assigned IP address and you want to grab this dynamic IP every-time the computer boots up and then use that value within your scripts? With iptables-restore, this is more or less impossible.

解决这个问题的一种可能性是制作一个小脚本，获取您想要在脚本中使用的值，然后使用 sed iptables-restore 文件查找特定关键字，并将它们替换为通过小脚本收集的值。此时，您可以将其保存到临时文件，然后使用 iptables-restore 加载新值。然而，这会导致很多问题，并且您将无法正确使用 iptables-save，因为它可能会删除您在恢复脚本中手动添加的关键字。换句话说，这是一个笨拙的解决方案。

One possibility to get around this is to make a small script which grabs the values you would like to use in the script, then sed the iptables-restore file for specific keywords and replace them with the values collected via the small script. At this point, you could save it to a temporary file, and then use iptables-restore to load the new values. This causes a lot of problems however, and you will be unable to use iptables-save properly since it would probably erase your manually added keywords in the restore script. It is, in other words, a clumsy solution.

第二种可能性是按照前面描述的那样进行。制作一个以 iptables-restore 格式输出规则的脚本，然后将它们提供给 iptables-restore 的标准输入。对于非常大的规则集，这比运行 iptables 本身更好，因为它有一个坏习惯，即在非常大的规则集上占用大量处理能力，如本章前面所述。

A second possibility is to do as previously described. Make a script that outputs rules in iptables-restore format, and then feed them on standard input of iptables-restore. For very large rulesets this would be to be preferred over running iptables itself, since it has a bad habit of taking a lot of processing power on very large rulesets as previously described in this chapter.

另一种解决方案是首先加载 iptables-restore 脚本，然后加载特定的 shell 脚本，该脚本在适当的位置插入更多动态规则。当然，正如您所理解的，这与第一个解决方案一样笨拙。iptables-restore 不太适合将 IP 地址动态分配给防火墙的配置，或者您希望根据配置选项采取不同行为的配置等。

Another solution is to load the iptables-restore scripts first, and then load a specific shell script that inserts more dynamic rules in their proper places. Of course, as you can understand, this is just as clumsy as the first solution. iptables-restore is simply not very well suited for configurations where IP addresses are dynamically assigned to your firewall or where you want different behaviors depending on configuration options and so on.

iptables-restore 和 iptables-save 的另一个缺点是，在编写本文时它还没有完全发挥作用。问题很简单，到目前为止，没有很多人使用它，因此没有很多人发现错误，反过来，一些匹配和目标将简单地插入错误，这可能会导致你所做的一些奇怪的行为没想到。尽管存在这些问题，我还是强烈建议使用这些工具，只要它们不包含一些不知道如何正确处理的新目标或匹配项，它们对于大多数规则集都应该非常有效。

Another drawback with iptables-restore and iptables-save is that it is not fully functional as of writing this. The problem is simply that not a lot of people use it as of today and hence there are not a lot of people finding bugs, and in turn some matches and targets will simply be inserted badly, which may lead to some strange behaviors that you did not expect. Even though these problems exist, I would highly recommend using these tools which should work extremely well for most rule-sets as long as they do not contain some of the new targets or matches that it does not know how to handle properly.

iptables-保存

iptables-save

正如我们已经解释过的，iptables-save 命令是一个将当前规则集保存到 iptables-restore 可以使用的文件中的工具。这个命令确实非常简单，只需要两个参数。查看以下示例以了解该命令的语法。

The iptables-save command is, as we have already explained, a tool to save the current rule-set into a file that iptables-restore can use. This command is quite simple really, and takes only two arguments. Take a look at the following example to understand the syntax of the command.

iptables-save [-c] [-t表]

iptables-save [-c] [-t table]

-c 参数告诉 iptables-save 保留字节和数据包计数器中指定的值。例如，如果我们想重新启动主防火墙，但又不想丢失可用于统计目的的字节和数据包计数器，则这可能很有用。发出带有 -c 参数的 iptables-save 命令将使我们能够在不破坏统计和会计例程的情况下重新启动。当然，默认值是在发出此命令时不保持计数器完整。

The -c argument tells iptables-save to keep the values specified in the byte and packet counters. This could for example be useful if we would like to reboot our main firewall, but not lose byte and packet counters which we may use for statistical purposes. Issuing a iptables-save command with the -c argument would then make it possible for us to reboot without breaking our statistical and accounting routines. The default value is, of course, to not keep the counters intact when issuing this command.

-t 参数告诉 iptables-save 命令要保存哪些表。如果没有此参数，该命令将自动将所有可用表保存到文件中。以下示例说明了在未加载任何规则集的情况下 iptables-save 命令会出现什么输出。

The -t argument tells the iptables-save command which tables to save. Without this argument the command will automatically save all tables available into the file. The following is an example on what output you can expect from the iptables-save command if you do not have any rule-set loaded.

# 由 iptables-save v1.2.6a 于 2002 年 4 月 24 日星期三 10:19:17 生成
*筛选
：输入接受[404：19766]
：转发接受[0:0]
：输出接受 [530:43376]
犯罪
# 于 2002 年 4 月 24 日星期三 10:19:17 完成
# 由 iptables-save v1.2.6a 于 2002 年 4 月 24 日星期三 10:19:17 生成
*损坏
:PREROUTING接受[451:22060]
：输入接受[451:22060]
：转发接受[0:0]
：输出接受 [594:47151]
: 后路由接受 [594:47151]
犯罪
# 于 2002 年 4 月 24 日星期三 10:19:17 完成
# 由 iptables-save v1.2.6a 于 2002 年 4 月 24 日星期三 10:19:17 生成
*nat
:PREROUTING接受[0:0]
：后路由接受 [3:450]
：输出接受 [3:450]
犯罪
# 于 2002 年 4 月 24 日星期三 10:19:17 完成

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*filter
:INPUT ACCEPT [404:19766]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [530:43376]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*mangle
:PREROUTING ACCEPT [451:22060]
:INPUT ACCEPT [451:22060]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [594:47151]
:POSTROUTING ACCEPT [594:47151]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
COMMIT
# Completed on Wed Apr 24 10:19:17 2002

其中包含一些以 # 符号开头的注释。每个表都标记为 *<table-name>，例如 *mangle。然后在每个表中我们都有链规范和规则。链规范类似于：<chain-name> <chain-policy> [<packet-counter>:<byte-counter>]。链名称可以是例如 PREROUTING，策略之前已描述并且可以是例如 ACCEPT。最后，数据包计数器和字节计数器与 iptables -L -v 的输出中的计数器相同。最后，每个表声明以 COMMIT 关键字结束。COMMIT 关键字告诉我们，此时我们应该将管道中当前的所有规则提交到内核。

This contains a few comments starting with a # sign. Each table is marked like *<table-name>, for example *mangle. Then within each table we have the chain specifications and rules. A chain specification looks like :<chain-name> <chain-policy> [<packet-counter>:<byte-counter>]. The chain-name may be for example PREROUTING, the policy is described previously and can, for example, be ACCEPT. Finally the packet-counter and byte-counters are the same counters as in the output from iptables -L -v. Finally, each table declaration ends in a COMMIT keyword. The COMMIT keyword tells us that at this point we should commit all rules currently in the pipeline to kernel.

上面的示例非常基本，因此我认为展示一个包含非常小的Iptables-save 规则集的简短示例是正确的。如果我们对此运行 iptables-save，输出将如下所示：

The above example is pretty basic, and hence I believe it is nothing more than proper to show a brief example which contains a very small Iptables-save ruleset. If we would run iptables-save on this, it would look something like this in the output:

# 由 iptables-save v1.2.6a 于 2002 年 4 月 24 日星期三 10:19:55 生成
*筛选
：输入下降 [1:229]
: 向前下降 [0:0]
：输出下降[0:0]
-A 输入 -m 状态 --state 相关，已建立 -j 接受
-A FORWARD -i eth0 -m state --state 相关，已建立 -j 接受
-A FORWARD -i eth1 -m state --state 新的、相关的、已建立的 -j 接受
-A 输出 -m 状态 --state 新的、相关的、已建立的 -j 接受
犯罪
# 于 2002 年 4 月 24 日星期三 10:19:55 完成
# 由 iptables-save v1.2.6a 于 2002 年 4 月 24 日星期三 10:19:55 生成
*损坏
:PREROUTING接受 [658:32445]
：输入接受[658:32445]
：转发接受[0:0]
：输出接受 [891:68234]
: 后路由接受 [891:68234]
犯罪
# 于 2002 年 4 月 24 日星期三 10:19:55 完成
# 由 iptables-save v1.2.6a 于 2002 年 4 月 24 日星期三 10:19:55 生成
*nat
:PREROUTING接受 [1:229]
：后路由接受 [3:450]
：输出接受 [3:450]
-A POSTROUTING -o eth0 -j SNAT --to-source 195.233.192.1
犯罪
# 于 2002 年 4 月 24 日星期三 10:19:55 完成

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*filter
:INPUT DROP [1:229]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*mangle
:PREROUTING ACCEPT [658:32445]
:INPUT ACCEPT [658:32445]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [891:68234]
:POSTROUTING ACCEPT [891:68234]
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*nat
:PREROUTING ACCEPT [1:229]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
-A POSTROUTING -o eth0 -j SNAT --to-source 195.233.192.1 
COMMIT
# Completed on Wed Apr 24 10:19:55 2002

正如您所看到的，自从我们使用 -c 参数以来，每个命令现在都以字节和数据包计数器为前缀。除此之外，脚本中的命令行非常完整。现在唯一的问题是如何将输出保存到文件中。非常简单，如果您以前使用过 Linux，您应该已经知道如何执行此操作。只需将命令输出通过管道传输到您想要另存为的文件即可。这可能如下所示：

As you can see, each command has now been prefixed with the byte and packet counters since we used the -c argument. Except for this, the command-line is quite intact from the script. The only problem now, is how to save the output to a file. Quite simple, and you should already know how to do this if you have used linux at all before. It is only a matter of piping the command output on to the file that you would like to save it as. This could look like the following:

iptables-save -c > /etc/iptables-save

iptables-save -c > /etc/iptables-save

换句话说，上面的命令会将整个规则集保存到名为/etc/iptables-save的文件中，并且字节和数据包计数器仍然完好无损。

The above command will in other words save the whole rule-set to a file called /etc/iptables-save with byte and packet counters still intact.

iptables-恢复

iptables-restore

iptables-restore 命令用于恢复使用 iptables-save 命令保存的 iptables 规则集。不幸的是，它从标准输入获取所有输入，并且在编写本文时无法从文件加载。这是 iptables-restore 的命令语法：

The iptables-restore command is used to restore the iptables rule-set that was saved with the iptables-save command. It takes all the input from standard input and can't load from files as of writing this, unfortunately. This is the command syntax for iptables-restore:

iptables-恢复 [-c] [-n]

iptables-restore [-c] [-n]

-c 参数可恢复字节和数据包计数器，如果要恢复之前使用 iptables-save 保存的计数器，则必须使用 -c 参数。这个论证也可以写成它的长形式——counters。

The -c argument restores the byte and packet counters and must be used if you want to restore counters that were previously saved with iptables-save. This argument may also be written in its long form --counters.

-n 参数告诉 iptables-restore 不要覆盖它正在写入的一个或多个表中先前写入的规则。iptables-restore 的默认行为是刷新并销毁所有先前插入的规则。短 -n 参数也可以替换为较长的格式 --noflush。

The -n argument tells iptables-restore to not overwrite the previously written rules in the table, or tables, that it is writing to. The default behavior of iptables-restore is to flush and destroy all previously inserted rules. The short -n argument may also be replaced with the longer format --noflush.

要使用 iptables-restore 命令加载规则集，我们可以通过多种方式执行此操作，但这里我们将主要介绍最简单和最常见的方法。

To load a rule-set with the iptables-restore command, we could do this in several ways, but we will mainly look at the simplest and most common way here.

    猫 /etc/iptables-save | iptables-恢复-c
   

    cat /etc/iptables-save | iptables-restore -c
   

以下也将起作用：

The following will also work:

     iptables-restore -c < /etc/iptables-save
   

     iptables-restore -c < /etc/iptables-save
   

这将捕获位于/etc/iptables-save文件中的规则集 ，然后通过管道将其传输到 iptables-restore，后者在标准输入上获取规则集，然后恢复它，包括字节和数据包计数器。开始就是这么简单。这个命令可以变化，直到被遗忘，我们可以显示不同的管道可能性，但是，这有点超出了本章的范围，因此我们将跳过该部分并将其作为练习留给读者进行实验。

This would cat the rule-set located within the /etc/iptables-save file and then pipe it to iptables-restore which takes the rule-set on the standard input and then restores it, including byte and packet counters. It is that simple to begin with. This command could be varied until oblivion and we could show different piping possibilities, however, this is a bit out of the scope of this chapter, and hence we will skip that part and leave it as an exercise for the reader to experiment with.

规则集现在应该正确加载到内核，并且一切都应该正常工作。如果没有，您可能在这些命令中遇到了错误。

The rule-set should now be loaded properly to kernel and everything should work. If not, you may possibly have run into a bug in these commands.

下一步是什么？

What's next?

本章在一定程度上讨论了 iptables-save 和 iptables-restore 程序以及它们的使用方法。这两个应用程序都随 iptables 软件包一起分发，可用于快速保存大型规则集，然后将它们再次插入内核中。

This chapter has discussed the iptables-save and iptables-restore programs to some extent and how they can be used. Both applications are distributed with the iptables package, and can be used to quickly save large rulesets and then inserting them into the kernel again.

下一章将介绍 iptables 规则的语法以及如何编写格式正确的规则集。它还将根据需要展示一些需要遵守的基本良好编码风格。

The next chapter will take a look at the syntax of a iptables rule and how to write properly formatted rule-sets. It will also show some basic good coding styles to adhere to, as required.

iptables 命令的基础知识

Basics of the iptables command

正如我们已经解释过的，每条规则都是内核查看的一行，以找出如何处理数据包。如果满足所有条件或匹配，我们将执行目标或跳转指令。通常我们会用如下语法编写规则：

As we have already explained, each rule is a line that the kernel looks at to find out what to do with a packet. If all the criteria - or matches - are met, we perform the target - or jump - instruction. Normally we would write our rules in a syntax that looks something like this:

iptables [-t table ] 命令 [匹配] [目标/跳转]

iptables [-t table] command [match] [target/jump]

没有任何规定说目标指令必须是该行中的最后一个函数。但是，您通常会遵守此语法以获得最佳的可读性。无论如何，您将看到的大多数规则都是以这种方式编写的。因此，如果您阅读别人的脚本，您很可能会识别语法并轻松理解规则。

There is nothing that says that the target instruction has to be the last function in the line. However, you would usually adhere to this syntax to get the best readability. Anyway, most of the rules you'll see are written in this way. Hence, if you read someone else's script, you'll most likely recognize the syntax and easily understand the rule.

如果要使用标准表以外的表，可以在指定 [table] 的位置插入表规范。但是，没有必要明确说明要使用哪个表，因为默认情况下 iptables 使用过滤器表来执行所有命令。您也不必在规则的此时指定表。它几乎可以设置在沿线的任何地方。然而，将表规范放在开头或多或少是标准的。

If you want to use a table other than the standard table, you could insert the table specification at the point at which [table] is specified. However, it is not necessary to state explicitly what table to use, since by default iptables uses the filter table on which to implement all commands. Neither do you have to specify the table at just this point in the rule. It could be set pretty much anywhere along the line. However, it is more or less standard to put the table specification at the beginning.

但需要考虑的一件事是：该命令应该始终位于第一位，或者直接位于表规范之后。我们使用“命令”来告诉程序要做什么，例如插入规则或将规则添加到链的末尾，或者删除规则。我们将在下面进一步探讨这一点。

One thing to think about though: The command should always come first, or alternatively directly after the table specification. We use 'command' to tell the program what to do, for example to insert a rule or to add a rule to the end of the chain, or to delete a rule. We shall take a further look at this below.

匹配是我们发送到内核的规则的一部分，它详细说明了数据包的特定字符，这使得它与所有其他数据包不同。在这里，我们可以指定数据包来自哪个 IP 地址、来自哪个网络接口、预期的 IP 地址、端口、协议等。我们可以使用大量不同的匹配，我们将在本章中进一步仔细研究它们。

The match is the part of the rule that we send to the kernel that details the specific character of the packet, what makes it different from all other packets. Here we could specify what IP address the packet comes from, from which network interface, the intended IP address, port, protocol or whatever. There is a heap of different matches that we can use that we will look closer at further on in this chapter.

最后我们得到了数据包的目标。如果数据包满足所有匹配，我们会告诉内核如何处理它。例如，我们可以告诉内核将数据包发送到我们自己创建的另一个链，并且该链是该特定表的一部分。我们可以告诉内核将数据包丢弃并且不再进行进一步处理，或者我们可以告诉内核向发送者发送指定的回复。与本节的其余内容一样，我们将在本章中进一步仔细研究它。

Finally we have the target of the packet. If all the matches are met for a packet, we tell the kernel what to do with it. We could, for example, tell the kernel to send the packet to another chain that we've created ourselves, and which is part of this particular table. We could tell the kernel to drop the packet dead and do no further processing, or we could tell the kernel to send a specified reply to the sender. As with the rest of the content in this section, we'll look closer at it further on in the chapter.

表格

Tables

-t 选项指定要使用哪个表。默认情况下，使用过滤表。我们可以使用 -t 选项指定下表之一。请注意，这是对表和链的遍历章节的一些内容的极其简短的总结 。

The -t option specifies which table to use. Per default, the filter table is used. We may specify one of the following tables with the -t option. Do note that this is an extremely brief summary of some of the contents of the Traversing of tables and chains chapter.

上述详细信息应该已经解释了可用的三个不同表格的基础知识。它们应该用于完全不同的目的，并且您应该知道每个链的用途。如果你不了解它们的用法，你很可能会在你的防火墙中给自己挖一个坑，一旦有人发现它并把你推进去，你就会掉进去。我们已经在遍历表和链章节中更详细地讨论了必要的表和链。如果你没有完全理解这一点，我建议你回去再读一遍。

The above details should have explained the basics about the three different tables that are available. They should be used for totally different purposes, and you should know what to use each chain for. If you do not understand their usage, you may well dig a pit for yourself in your firewall, into which you will fall as soon as someone finds it and pushes you into it. We have already discussed the requisite tables and chains in more detail within the Traversing of tables and chains chapter. If you do not understand this fully, I advise you to go back and read through it again.

命令

Commands

在本节中，我们将介绍所有不同的命令以及它们可以做什么。该命令告诉 iptables 如何处理我们发送到解析器的其余规则。通常我们想要在某个表或另一个表中添加或删除某些内容。iptables 可以使用以下命令：

In this section we will cover all the different commands and what can be done with them. The command tells iptables what to do with the rest of the rule that we send to the parser. Normally we would want either to add or delete something in some table or another. The following commands are available to iptables:

您应该始终输入完整的命令行，除非您只想列出 iptables 的内置帮助或获取命令的版本。要获取版本，请使用 -v 选项；要获取帮助消息，请使用 -h 选项。换句话说，和往常一样。接下来是一些可与各种不同命令一起使用的选项。请注意，我们会告诉您这些选项可以与哪些命令一起使用以及它们将产生什么效果。另请注意，我们此处不包含任何影响规则或匹配的选项。相反，我们将在本章后面的部分中讨论匹配和目标。

You should always enter a complete command line, unless you just want to list the built-in help for iptables or get the version of the command. To get the version, use the -v option and to get the help message, use the -h option. As usual, in other words. Next comes a few options that can be used with various different commands. Note that we tell you with which commands the options can be used and what effect they will have. Also note that we do not include any options here that affect rules or matches. Instead, we'll take a look at matches and targets in a later section of this chapter.

下一步是什么？

What's next?

本章非常简单地讨论了 iptables 的一些基本命令以及可在 netfilter 中使用的表。正如您所看到的，这些命令可以对加载到内核中的 netfilter 包执行许多不同的操作。

This chapter has discussed some of the basic commands for iptables and the tables very briefly that can be used in netfilter. The commands makes it possible to do quite a lot of different operations on the netfilter package loaded inside kernel as you have seen.

下一章将讨论 iptables 和 netfilter 中所有可用的匹配。这是一个非常沉重和漫长的章节，我谦虚地建议你不需要真正详细地学习每一个可用的匹配，除了你将要使用的那些。一个好主意可能是简要了解每场比赛的作用，然后在需要时更好地掌握它们。

The next chapter will discuss all the available matches in iptables and netfilter. This is a very heavy and long chapter, and I humbly suggest that you don't need to actually learn every single match available in any detail, except the ones that you are going to use. A good idea might be to get a brief understanding of what each match does, and then get a better grasp on them as you need them.

通用匹配

Generic matches

本节将处理通用匹配。通用匹配是一种始终可用的匹配，无论我们正在使用哪种类型的协议，或者我们加载的任何匹配扩展。使用这些匹配根本不需要任何特殊参数；换句话说。我还在此处包含了 --protocol 匹配，尽管它更具体于协议匹配。例如，如果我们想使用 TCP 匹配，我们需要使用 --protocol 匹配并将 TCP 作为选项发送到匹配。然而，--protocol 本身也是一个匹配，因为它可以用来匹配特定的协议。以下比赛始终可用。

This section will deal with Generic matches. A generic match is a kind of match that is always available, whatever kind of protocol we are working on, or whatever match extensions we have loaded. No special parameters at all are needed to use these matches; in other words. I have also included the --protocol match here, even though it is more specific to protocol matches. For example, if we want to use a TCP match, we need to use the --protocol match and send TCP as an option to the match. However, --protocol is also a match in itself, since it can be used to match specific protocols. The following matches are always available.

隐式匹配

Implicit matches

本节将描述隐式加载的匹配项。隐式匹配是暗示的、理所当然的、自动的。例如，当我们在没有任何进一步条件的情况下匹配 --protocol tcp 时。目前存在针对三种不同协议的三种类型的隐式匹配。它们是TCP 匹配、UDP 匹配和ICMP 匹配。基于 TCP 的匹配包含一组仅适用于 TCP 数据包的唯一标准。基于 UDP 的匹配包含另一组仅适用于 UDP 数据包的条件。ICMP 数据包也是如此。另一方面，可能存在显式加载的显式匹配。显式匹配不是暗示或自动的，您必须具体指定它们。对于这些，您可以使用 -m 或 --match 选项，我们将在下一节中讨论。

This section will describe the matches that are loaded implicitly. Implicit matches are implied, taken for granted, automatic. For example when we match on --protocol tcp without any further criteria. There are currently three types of implicit matches for three different protocols. These are TCP matches, UDP matches and ICMP matches. The TCP based matches contain a set of unique criteria that are available only for TCP packets. UDP based matches contain another set of criteria that are available only for UDP packets. And the same thing for ICMP packets. On the other hand, there can be explicit matches that are loaded explicitly. Explicit matches are not implied or automatic, you have to specify them specifically. For these you use the -m or --match option, which we will discuss in the next section.

---

ICMP 匹配

ICMP matches

这些是ICMP 匹配。这些数据包比 UDP 数据包更加短暂，即寿命较短，因为它们是无连接的。ICMP协议主要用于错误报告和连接控制等。ICMP 不是一个从属于 IP 协议的协议，而是一个增强 IP 协议并帮助处理错误的协议。ICMP 数据包的标头与 IP 标头非常相似，但在许多方面有所不同。该协议的主要特征是类型标头，它告诉我们数据包的用途。一个例子是，如果我们尝试访问一个无法访问的 IP 地址，通常会得到一个无法访问的 ICMP 主机作为回报。有关 ICMP 类型的完整列表，请参阅ICMP 类型附录。ICMP 数据包只有一个 ICMP 特定匹配可用，希望这应该足够了。当我们使用 --protocol ICMP 匹配时，此匹配会被隐式加载，并且我们会自动访问它。请注意，还可以使用所有通用匹配，以便我们可以在源地址和目标地址上进行匹配。

These are the ICMP matches. These packets are even more ephemeral, that is to say short lived, than UDP packets, in the sense that they are connectionless. The ICMP protocol is mainly used for error reporting and for connection controlling and suchlike. ICMP is not a protocol subordinated to the IP protocol, but more of a protocol that augments the IP protocol and helps in handling errors. The headers of ICMP packets are very similar to those of the IP headers, but differ in a number of ways. The main feature of this protocol is the type header, that tells us what the packet is for. One example is, if we try to access an unaccessible IP address, we would normally get an ICMP host unreachable in return. For a complete listing of ICMP types, see the ICMP types appendix. There is only one ICMP specific match available for ICMP packets, and hopefully this should suffice. This match is implicitly loaded when we use the --protocol ICMP match and we get access to it automatically. Note that all the generic matches can also be used, so that among other things we can match on the source and destination addresses.

表 10-4。ICMP 匹配

Table 10-4. ICMP matches

匹配	--icmp 类型
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输入 -p icmp --icmp 类型 8
解释	该匹配用于指定要匹配的 ICMP 类型。ICMP 类型可以通过其数值或名称来指定。RFC 792 中指定了数值。要查找 ICMP 名称值的完整列表，请执行 iptables --protocol icmp --help，或检查ICMP 类型附录。这场比赛也可以用 ! 登录此 --icmp-type ！8、时尚。请注意，某些 ICMP 类型已过时，而其他类型对于未受保护的主机来说可能又是“危险的”，因为它们可能会将数据包重定向到错误的位置。类型和代码也可以通过它们的类型名称、数字类型和类型/代码来指定。例如 --icmp-type 网络重定向、--icmp-type 8 或 --icmp-type 8/0。要获得完整的名称列表，请输入 iptables -p icmp --help。 This match is used to specify the ICMP type to match. ICMP types can be specified either by their numeric values or by their names. Numerical values are specified in RFC 792. To find a complete listing of the ICMP name values, do an iptables --protocol icmp --help, or check the ICMP types appendix. This match can also be inverted with the ! sign in this, --icmp-type ! 8, fashion. Note that some ICMP types are obsolete, and others again may be "dangerous" for an unprotected host since they may, among other things, redirect packets to the wrong places. The type and code may also be specified by their typename, numeric type, and type/code as well. For example --icmp-type network-redirect, --icmp-type 8 or --icmp-type 8/0. For a complete listing of the names, type iptables -p icmp --help. 请注意，netfilter 使用 ICMP 类型 255 来匹配所有 ICMP 类型。如果您尝试匹配此 ICMP 类型，您最终将匹配所有 ICMP 类型。 Please note that netfilter uses ICMP type 255 to match all ICMP types. If you try to match this ICMP type, you will wind up with matching all ICMP types.

显式匹配

Explicit matches

显式匹配是那些必须使用 -m 或 --match 选项专门加载的匹配。例如，状态匹配需要在输入要使用的实际匹配之前使用指令 -m state。其中一些匹配可能是特定于协议的。有些可能未与任何特定协议连接 - 例如连接状态。这些可能是NEW（尚未建立的连接的第一个数据包）、ESTABLISHED（已在内核中注册的连接）、RELATED（由较旧的已建立连接创建的新连接）等。是为了测试或实验目的而演变的，或者只是为了说明 iptables 的能力。这反过来意味着并非所有这些匹配乍一看都有任何用处。尽管如此，您个人很可能会发现特定显式匹配的用途。并且随着每个新的 iptables 版本的出现，总会有新的出现。您是否找到它们的用途取决于您的想象力和需求。隐式加载的匹配和显式加载的匹配之间的区别在于，例如，当您匹配 TCP 数据包的属性时，隐式加载的匹配将自动加载，而显式加载的匹配永远不会自动加载 - 这取决于您发现并激活显式匹配。

Explicit matches are those that have to be specifically loaded with the -m or --match option. State matches, for example, demand the directive -m state prior to entering the actual match that you want to use. Some of these matches may be protocol specific . Some may be unconnected with any specific protocol - for example connection states. These might be NEW (the first packet of an as yet unestablished connection), ESTABLISHED (a connection that is already registered in the kernel), RELATED (a new connection that was created by an older, established one) etc. A few may just have been evolved for testing or experimental purposes, or just to illustrate what iptables is capable of. This in turn means that not all of these matches may at first sight be of any use. Nevertheless, it may well be that you personally will find a use for specific explicit matches. And there are new ones coming along all the time, with each new iptables release. Whether you find a use for them or not depends on your imagination and your needs. The difference between implicitly loaded matches and explicitly loaded ones, is that the implicitly loaded matches will automatically be loaded when, for example, you match on the properties of TCP packets, while explicitly loaded matches will never be loaded automatically - it is up to you to discover and activate explicit matches.

---

AH/ESP 匹配

AH/ESP match

这些匹配用于 IPSEC AH 和 ESP 协议。IPSEC 用于通过不安全的 Internet 连接创建安全隧道。IPSEC 使用 AH 和 ESP 协议来创建这些安全连接。AH 和 ESP 匹配实际上是两个独立的匹配，但这里都进行了描述，因为它们看起来非常相似，并且都在同一函数中使用。

These matches are used for the IPSEC AH and ESP protocols. IPSEC is used to create secure tunnels over an insecure Internet connection. The AH and ESP protocols are used by IPSEC to create these secure connections. The AH and ESP matches are really two separate matches, but are both described here since they look very much alike, and both are used in the same function.

这里我不会详细描述IPSEC，而是查看以下页面和文档以获取更多信息：

I will not go into detail to describe IPSEC here, instead look at the following pages and documents for more information:

• RFC 2401 - 互联网协议的安全架构

• RFC 2401 - Security Architecture for the Internet Protocol

• 自由网络/广域网

• FreeS/WAN

• IPSEC 指南

• IPSEC Howto

• Linux 高级路由和流量控制操作指南

• Linux Advanced Routing and Traffic Control HOW-TO

互联网上还有大量与此相关的文档，但您可以根据需要随意查找。

There is also a ton more documentation on the Internet on this, but you are free to look it up as needed.

要使用 AH/ESP 匹配，您需要使用 -m ah 加载 AH 匹配，使用 -m esp 加载 ESP 匹配。

To use the AH/ESP matches, you need to use -m ah to load the AH matches, and -m esp to load the ESP matches.

在 2.2 和 2.4 内核中，Linux 使用称为 FreeS/WAN 的东西来实现 IPSEC，但从 Linux 内核 2.5.47 及更高版本开始，Linux 内核直接实现 IPSEC，无需对内核进行修补。这是对 Linux 上 IPSEC 实现的完全重写。 In 2.2 and 2.4 kernels, Linux used something called FreeS/WAN for the IPSEC implementation, but as of Linux kernel 2.5.47 and up, Linux kernels have a direct implementation of IPSEC that requires no patching of the kernel. This is a total rewrite of the IPSEC implementation on Linux.

表 10-8。AH 匹配选项

Table 10-8. AH match options

匹配	--ahspi
核心	2.5 和 2.6
例子	iptables -A 输入 -p 51 -m ah --ahspi 500
解释	这与 AH 数据包的 AH 安全参数索引 (SPI) 编号相匹配。请注意，您还必须指定协议，因为 AH 运行的协议与标准 TCP、UDP 或 ICMP 协议不同。SPI 编号与源地址、目标地址以及密钥一起使用来创建安全关联 (SA)。SA 唯一标识通往所有主机的每一条 IPSEC 隧道。SPI 用于唯一区分相同两个对等点之间连接的每个 IPSEC 隧道。使用 --ahspi 匹配，我们可以根据数据包的 SPI 来匹配数据包。此匹配可以通过使用 : 符号来匹配整个 SPI 值范围，例如 500:520，这将匹配 SPI 的整个范围。

表 10-9。ESP 匹配选项

Table 10-9. ESP match options

匹配	--essppi
核心	2.5 和 2.6
例子	iptables -A 输入 -p 50 -m esp --essppi 500
解释	ESP 对应的安全参数索引 (SPI) 的使用方式与 AH 变体完全相同。比赛看起来完全一样，只是 esp/ah 不同。当然，该匹配可以匹配整个 SPI 数字范围以及 SPI 匹配的 AH 变体，例如 --essppi 200:250 匹配整个 SPI 范围。

---

康马克比赛

Connmark match

connmark 匹配的使用方式与 MARK/mark 目标和匹配组合中的标记匹配非常相似。connmark 匹配用于匹配在与 CONNMARK 目标的连接上设置的标记。只需要一个选项。

The connmark match is used very much the same way as the mark match is in the MARK/mark target and match combination. The connmark match is used to match marks that has been set on a connection with the CONNMARK target. It only takes one option.

要在与第一个创建连接标记的同一数据包上匹配标记，必须在 CONNMARK 目标在第一个数据包上设置标记后使用 connmark 匹配。 To match a mark on the same packet as is the first to create the connection marking, you must use the connmark match after the CONNMARK target has set the mark on the first packet.

表 10-11。康马克匹配选项

Table 10-11. Connmark match options

匹配	- 标记
核心	2.6
例子	iptables -A 输入 -m connmark --mark 12 -j 接受
解释	标记选项用于匹配与连接关联的特定标记。标记匹配必须精确，如果您想在实际匹配任何内容之前从连接标记中过滤掉不需要的标志，您可以指定一个将与连接标记进行与运算的掩码。例如，如果您在连接上将连接标记设置为 33（二进制为 10001），并且只想匹配第一位，则可以运行类似 --mark 1/1 的命令。掩码 (00001) 将被掩码为 10001，因此 10001 && 00001 等于 1，然后与 1 进行匹配。 The mark option is used to match a specific mark associated with a connection. The mark match must be exact, and if you want to filter out unwanted flags from the connection mark before actually matching anything, you can specify a mask that will be anded to the connection mark. For example, if you have a connection mark set to 33 (10001 in binary) on a connection, and want to match the first bit only, you would be able to run something like --mark 1/1. The mask (00001) would be masked to 10001, so 10001 && 00001 equals 1, and then matched against the 1.

---

DSCP 匹配

Dscp match

此匹配用于根据数据包的 DSCP（差分服务代码点）字段进行匹配。这记录在RFC 2638 - 用于互联网 RFC 的两位差分服务架构中。通过指定 -m dscp 显式加载匹配。匹配可以采用两个互斥的选项，如下所述。

This match is used to match on packets based on their DSCP (Differentiated Services Code Point) field. This is documented in the RFC 2638 - A Two-bit Differentiated Services Architecture for the Internet RFC. The match is explicitly loaded by specifying -m dscp. The match can take two mutually exclusive options, described below.

表 10-13。Dscp 匹配选项

Table 10-13. Dscp match options

匹配	--dscp
核心	2.5 和 2.6
例子	iptables -A 输入 -p tcp -m dscp --dscp 32
解释	此选项采用十进制或十六进制形式的 DSCP 值。如果选项值是十进制，则可以写为 32 或 16 等。如果以十六进制书写，则应以 0x 为前缀，如下所示：0x20。也可以使用 ! 来反转它。字符，像这样： -m dscp ! --dscp 32。 This option takes a DSCP value in either decimal or in hex. If the option value is in decimal, it would be written like 32 or 16, et cetera. If written in hex, it should be prefixed with 0x, like this: 0x20. It can also be inverted by using the ! character, like this: -m dscp ! --dscp 32.
匹配	--dscp 类
核心	2.5 和 2.6
例子	iptables -A 输入 -p tcp -m dscp --dscp-class BE
解释	--dscp-class 匹配用于匹配数据包的 DiffServ 类。这些值可以是各种 RFC 中指定的任何 BE、EF、AFxx 或 CSx 类。该匹配可以以与 --dscp 选项相同的方式反转。 The --dscp-class match is used to match on the DiffServ class of a packet. The values can be any of the BE, EF, AFxx or CSx classes as specified in the various RFC's. This match can be inverted just the same way as the --dscp option.

请注意，--dscp 和 --dscp-class 选项是互斥的，不能相互结合使用。 Please note that the --dscp and --dscp-class options are mutually exclusive and can not be used in conjunction with each other.

---

哈希限制匹配

Hashlimit match

这是极限比赛的修改版本。它不只是设置单个令牌桶，而是为每个目标 IP、源 IP、目标端口和源端口元组设置一个指向令牌桶的哈希表。例如，您可以将其设置为每个 IP 地址每秒最多可以接收 1000 个数据包，或者您可以说特定 IP 地址上的每个服务每秒最多可以接收 200 个数据包。hashlimit 匹配是通过指定 -m hashlimit 关键字来加载的。

This is a modified version of the Limit match. Instead of just setting up a single token bucket, it sets up a hash table pointing to token buckets for each destination IP, source IP, destination port and source port tuple. For example, you can set it up so that every IP address can receive a maximum of 1000 packets per second, or you can say that every service on a specific IP address may receive a maximum of 200 packets per second. The hashlimit match is loaded by specifying the -m hashlimit keywords.

每个使用 hashlimit 匹配的规则都会创建一个单独的哈希表，该哈希表又具有特定的最大大小和最大存储桶数。该哈希表包含单个或多个值的哈希。这些值可以是目标 IP、源 IP、目标端口和源端口中的任何一个和/或全部。然后，每个条目都指向一个充当限制匹配的令牌桶。

Each rule that uses the hashlimit match creates a separate hashtable which in turn has a specific max size and a maximum number of buckets. This hash table contains a hash of either a single or multiple values. The values can be any and/or all of destination IP, source IP, destination port and source port. Each entry then points to a token bucket that works as the limit match.

表 10-16。哈希限制匹配选项

Table 10-16. Hashlimit match options

匹配	--哈希限制
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000/秒 --hashlimit-mode dstip,dstport --hashlimit-name 主机
解释	--hashlimit 指定每个存储桶的限制。在此示例中，hashlimit 设置为 1000。在此示例中，我们将 hashlimit-mode 设置为 dstip、dstport 和目标 192.168.0.3。因此，对于目标主机上的每个端口或服务，它每秒可以接收 1000 个数据包。这与限制匹配的限制选项设置相同。该限制可以采用/秒、/分钟、/小时或/天后缀。如果未指定后缀，则默认后缀为每秒。 The --hashlimit specifies the limit of each bucket. In this example the hashlimit is set to 1000. In this example, we have set up the hashlimit-mode to be dstip,dstport and destination 192.168.0.3. Hence, for every port or service on the destination host, it can receive 1000 packets per second. This is the same setting as the limit option for the limit match. The limit can take a /sec, /minute, /hour or /day postfix. If no postfix is specified, the default postfix is per second. 对于所有 hashlimit 匹配，此选项是必需的。 This option is mandatory for all hashlimit matches.
匹配	--哈希限制模式
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.0/16 -m hashlimit --hashlimit 1000/秒 --hashlimit-mode dstip --hashlimit-name 主机
解释	--hashlimit-mode 选项指定我们应该使用哪些值作为哈希值。在此示例中，我们仅使用 dstip（目标 IP）作为哈希值。因此，在这种情况下，192.168.0.0/16 网络中的每台主机每秒最多接收 1000 个数据包。--hashlimit-mode 的可能值为 dstip（目标 IP）、srcip（源 IP）、dstport（目标端口）和 srcport（源端口）。所有这些也可以用逗号分隔以包含多个哈希值，例如 --hashlimit-mode dstip,dstport。 The --hashlimit-mode option specifies which values we should use as the hash values. In this example, we use only the dstip (destination IP) as the hashvalue. So, each host in the 192.168.0.0/16 network will be limited to receiving a maximum of 1000 packets per second in this case. The possible values for the --hashlimit-mode is dstip (Destination IP), srcip (Source IP), dstport (Destination port) and srcport (Source port). All of these can also be separated by a comma sign to include more than one hashvalue, such as for example --hashlimit-mode dstip,dstport. 对于所有 hashlimit 匹配，此选项是必需的。 This option is mandatory for all hashlimit matches.
匹配	--hashlimit-名称
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name 主机
解释	此选项指定此特定哈希可用的名称。可以在/proc/net/ipt_hashlimit 目录中查看。上面的示例可以在 /proc/net/ipt_hashlimit/hosts文件中查看。仅应指定文件名。 This option specifies the name that this specific hash will be available as. It can be viewed inside the /proc/net/ipt_hashlimit directory. The example above would be viewable inside the /proc/net/ipt_hashlimit/hosts file. Only the filename should be specified. 对于所有 hashlimit 匹配，此选项是必需的。 This option is mandatory for all hashlimit matches.
匹配	--hashlimit-爆发
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name 主机 --hashlimit-burst 2000
解释	此匹配与 --limit-burst 相同，它设置存储桶的最大大小。每个桶都会有一个突发限制，即单个时间单位内可以匹配的最大数据包数量。有关令牌桶如何工作的示例，请查看Limit match。 This match is the same as the --limit-burst in that it sets the maximum size of the bucket. Each bucket will have a burst limit, which is the maximum amount of packets that can be matched during a single time unit. For an example on how a token bucket works, take a look at the Limit match.
匹配	--hashlimit-htable-大小
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name 主机 --hashlimit-htable-size 500
解释	这设置了要使用的最大可用存储桶。在此示例中，这意味着最多可以同时打开和活动 500 个端口。 This sets the maximum available buckets to be used. In this example, it means that a maximum of 500 ports can be open and active at the same time.
匹配	--hashlimit-htable-max
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name 主机 --hashlimit-htable-max 500
解释	--hashlimit-htable-max 设置哈希表条目的最大数量。这意味着所有连接，包括暂时不需要任何令牌桶的非活动连接。 The --hashlimit-htable-max sets the maximum number of hashtable entries. This means all of the connections, including the inactive connections that doesn't require any token buckets for the moment.
匹配	--hashlimit-htable-gcinterval
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name 主机 --hashlimit-htable-gcinterval 1000
解释	垃圾收集功能应该多久运行一次。一般来说这个值应该低于expire值。该值以毫秒为单位测量。如果设置得太低，则会占用不必要的系统资源和处理能力，但如果设置得太高，则可能会使未使用的令牌桶闲置太久，并使其他连接无法进行。在此示例中，垃圾收集器将每秒运行一次。 How often should the garbage collection function be run. Generally speaking this value should be lower than the expire value. The value is measured in milliseconds. If it is set too low it will be taking up unnecessary system resources and processing power, but if it's too high it can leave unused token buckets lying around for too long and leaving other connections impossible. In this example the garbage collector will run every second.
匹配	--hashlimit-htable-过期
核心	2.6
例子	iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name 主机 --hashlimit-htable-expire 10000
解释	该值设置空闲哈希表条目在多长时间后到期。如果存储桶未使用的时间超过此时间，它将过期，并且下一次垃圾收集运行将从哈希表中删除它以及与其相关的所有信息。 This value sets after how long time an idle hashtable entry should expire. If a bucket has been unused for longer than this, it will be expired and the next garbage collection run will remove it from the hashtable, as well as all of the information pertaining to it.

---

Mac 比赛

Mac match

MAC（以太网媒体访问控制）匹配可用于根据数据包的 MAC 源地址来匹配数据包。在撰写本文档时，这种匹配有一点限制，但是，将来这可能会更加发展并且可能会更有用。如前所述，此匹配只能用于匹配源 MAC 地址上的数据包。

The MAC (Ethernet Media Access Control) match can be used to match packets based on their MAC source address. As of writing this documentation, this match is a little bit limited, however, in the future this may be more evolved and may be more useful. This match can be used to match packets on the source MAC address only as previously said.

请注意，要使用此模块，我们使用 -m mac 选项显式加载它。我这么说的原因是很多人想知道它是否不应该是 -m mac-source ，它不应该。 Do note that to use this module we explicitly load it with the -m mac option. The reason that I am saying this is that a lot of people wonder if it should not be -m mac-source, which it should not.

表 10-21。Mac 匹配选项

Table 10-21. Mac match options

匹配	--mac-源
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输入 -m mac --mac-source 00:00:00:00:00:01
解释	此匹配用于根据数据包的 MAC 源地址来匹配数据包。指定的 MAC 地址必须采用XX:XX:XX:XX:XX:XX格式 ，否则不合法。比赛可能会逆转！签名并且看起来像 --mac-source ！00:00:00:00:00:01。换句话说，这将颠倒匹配的含义，以便匹配除来自该 MAC 地址的数据包之外的所有数据包。请注意，由于 MAC 地址仅在以太网类型网络上使用，因此此匹配仅可用于以太网接口。MAC 匹配仅在 PREROUTING、FORWARD 和 INPUT 链中有效，在其他链中无效。

---

多端口匹配

Multiport match

多端口匹配扩展可用于指定多个目标端口和端口范围。如果没有这种匹配的可能性，您将不得不使用相同类型的多个规则，只是为了匹配不同的端口。

The multiport match extension can be used to specify multiple destination ports and port ranges. Without the possibility this match gives, you would have to use multiple rules of the same type, just to match different ports.

不能同时使用标准端口匹配和多端口匹配，例如不能写：--sport 1024:63353 -m multiport --dport 21,23,80。这根本行不通。如果您这样做，实际上会发生的情况是 iptables 遵循规则中的第一个元素，并忽略多端口指令。 You can not use both standard port matching and multiport matching at the same time, for example you can't write: --sport 1024:63353 -m multiport --dport 21,23,80. This will simply not work. What in fact happens, if you do, is that iptables honors the first element in the rule, and ignores the multiport instruction.

表 10-23。多端口匹配选项

Table 10-23. Multiport match options

匹配	--源端口
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输入 -p tcp -m 多端口 --源端口 22,53,80,110
解释	此匹配匹配多个源端口。最多可以指定 15 个单独的端口。端口必须以逗号分隔，如上例所示。该匹配只能与 -p tcp 或 -p udp 匹配结合使用。它主要是普通的 --source-port 匹配的增强版本。
匹配	- 目的端口
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输入 -p tcp -m 多端口 --目标端口 22,53,80,110
解释	该匹配用于匹配多个目标端口。它的工作方式与上面提到的源端口匹配完全相同，只是它匹配目标端口。它也有 15 个端口的限制，并且只能与 -p tcp 和 -p udp 结合使用。
匹配	- 港口
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输入 -p tcp -m 多端口 --端口 22,53,80,110
解释	此匹配扩展可用于根据数据包的目标端口和源端口来匹配数据包。它的工作方式与上面的 --source-port 和 --destination-port 匹配相同。它最多可以占用 15 个端口，并且只能与 -p tcp 和 -p udp 结合使用。请注意，--port 匹配将仅匹配来自和前往同一端口的数据包，例如，端口 80 到端口 80、端口 110 到端口 110 等。

---

业主匹配

Owner match

所有者匹配扩展用于根据创建数据包的进程的身份来匹配数据包。所有者可以指定为发出相关命令的用户、组、进程、会话或命令本身的进程 ID。该扩展最初是作为 iptables 用途的示例而编写的。所有者匹配仅在 OUTPUT 链内有效，原因很明显：几乎不可能找到有关从另一端发送数据包的实例的身份的任何信息，或者找到到达真实目的地的中间跃点的信息。即使在 OUTPUT 链内，它也不是很可靠，因为某些数据包可能没有所有者。此类臭名昭著的数据包（除其他外）是不同的 ICMP 响应。ICMP 响应永远不会匹配。

The owner match extension is used to match packets based on the identity of the process that created them. The owner can be specified as the process ID either of the user who issued the command in question, that of the group, the process, the session, or that of the command itself. This extension was originally written as an example of what iptables could be used for. The owner match only works within the OUTPUT chain, for obvious reasons: It is pretty much impossible to find out any information about the identity of the instance that sent a packet from the other end, or where there is an intermediate hop to the real destination. Even within the OUTPUT chain it is not very reliable, since certain packets may not have an owner. Notorious packets of that sort are (among other things) the different ICMP responses. ICMP responses will never match.

表 10-24。所有者匹配选项

Table 10-24. Owner match options

匹配	--cmd-所有者
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输出 -m 所有者 --cmd-所有者 httpd
解释	这是命令所有者匹配，用于根据发送数据包的进程的命令名称进行匹配。示例中匹配httpd。也可以使用感叹号来反转此匹配，例如 -m Owner ! --cmd-所有者 ssh。 This is the command owner match, and is used to match based on the command name of the process that is sending the packet. In the example, httpd is matched. This match may also be inverted by using an exclamation sign, for example -m owner ! --cmd-owner ssh.
匹配	--uid-所有者
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输出 -m 所有者 --uid-所有者 500
解释	如果数据包是由给定的用户 ID (UID) 创建的，则此数据包匹配将匹配。这可用于根据创建数据包的人来匹配传出数据包。一种可能的用途是阻止除 root 之外的任何其他用户在防火墙之外打开新连接。另一种可能的用途是阻止除 http 用户之外的所有人从 HTTP 端口发送数据包。
匹配	--gid-所有者
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输出 -m 所有者 --gid-所有者 0
解释	此匹配用于根据组 ID (GID) 匹配所有数据包。这意味着我们根据创建数据包的用户所在的组来匹配所有数据包。这可以用于阻止除网络组中的用户之外的所有用户访问互联网，或者如上所述，仅允许网络组中的成员访问互联网。 http 组创建从 HTTP 端口发出的数据包。
匹配	--pid-所有者
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输出 -m 所有者 --pid-所有者 78
解释	此匹配用于根据负责数据包的进程 ID (PID) 来匹配数据包。此匹配有点难以使用，但一个示例是仅允许 PID 94 从 HTTP 端口发送数据包（当然，如果 HTTP 进程不是线程化的）。或者，我们可以编写一个小脚本，从特定守护进程的 ps 输出中获取 PID，然后为其添加规则。例如，您可以拥有Pid-owner.txt示例中所示的规则。
匹配	--sid-所有者
核心	2.3、2.4、2.5 和 2.6
例子	iptables -A 输出 -m 所有者 --sid-所有者 100
解释	此匹配用于根据相关程序使用的会话 ID 来匹配数据包。进程的 SID 或会话 ID 的值是进程本身以及源自原始进程的所有进程的值。后者可以是线程，也可以是原始进程的子进程。因此，举例来说，如果我们的 HTTPD 是线程化的（大多数 HTTPD 都是线程化的，例如 Apache 和 Roxen），那么我们所有的 HTTPD 进程都应该与其父进程（原始 HTTPD 进程）具有相同的 SID。为了在示例中展示这一点，我们创建了一个名为Sid-owner.txt的小脚本。该脚本可能每小时左右运行一次，并结合一些额外的代码来检查 HTTPD 是否实际运行，并在必要时重新启动它，然后刷新并重新输入我们的 OUTPUT 链（如果需要）。

SMP 内核中的 pid、sid 和命令匹配被破坏，因为它们为每个处理器使用不同的进程列表。不过将来可能会修复 The pid, sid and command matching is broken in SMP kernels since they use different process lists for each processor. It might be fixed in the future however

---

最近的比赛

Recent match

最近的匹配是一个相当庞大和复杂的匹配系统，它允许我们根据之前匹配过的最近事件来匹配数据包。例如，如果我们看到一个传出的 IRC 连接，我们可以将 IP 地址设置到主机列表中，并设置另一条规则，允许在看到原始数据包后 15 秒内从 IRC 服务器返回 identd 请求。

The recent match is a rather large and complex matching system, which allows us to match packets based on recent events that we have previously matched. For example, if we would see an outgoing IRC connection, we could set the IP addresses into a list of hosts, and have another rule that allows identd requests back from the IRC server within 15 seconds of seeing the original packet.

在我们仔细研究匹配选项之前，让我们尝试解释一下它是如何工作的。首先，我们使用几种不同的规则来完成对最近匹配的使用。最近的比赛使用了几个不同的最近事件列表。使用的默认列表是 DEFAULT 列表。我们使用 set 选项在列表中创建一个新条目，因此一旦规则完全匹配（set 选项始终匹配），我们还会在指定的最近列表中添加一个条目。列表条目包含时间戳以及触发设置选项的数据包中使用的源 IP 地址。一旦发生这种情况，我们可以使用一系列不同的最近选项来匹配此信息，以及更新条目时间戳等。

Before we can take a closer look at the match options, let's try and explain a little bit how it works. First of all, we use several different rules to accomplish the use of the recent match. The recent match uses several different lists of recent events. The default list being used is the DEFAULT list. We create a new entry in a list with the set option, so once a rule is entirely matched (the set option is always a match), we also add an entry in the recent list specified. The list entry contains a timestamp, and the source IP address used in the packet that triggered the set option. Once this has happened, we can use a series of different recent options to match on this information, as well as update the entries timestamp, et cetera.

最后，如果我们出于某种原因想要删除列表条目，我们将使用最近匹配中的 --remove 匹配选项来执行此操作。所有使用最近匹配的规则都必须像往常一样加载最近的模块（-m最近）。在我们继续以最近的比赛为例之前，让我们先看一下所有选项。

Finally, if we would for some reason want to remove a list entry, we would do this using the --remove match option from the recent match. All rules using the recent match, must load the recent module (-m recent) as usual. Before we go on with an example of the recent match, let's take a look at all the options.

表 10-27。最近的比赛选项

Table 10-27. Recent match options

匹配	- 姓名
核心	2.4、2.5 和 2.6
例子	iptables -A 输出 -m 最近 --name examplelist
解释	name 选项给出要使用的列表的名称。默认情况下使用 DEFAULT 列表，如果我们使用多个列表，这可能不是我们想要的。 The name option gives the name of the list to use. Per default the DEFAULT list is used, which is probably not what we want if we are using more than one list.
匹配	- 放
核心	2.4、2.5 和 2.6
例子	iptables -A 输出 -m 最近 --set
解释	这会在命名的最近列表中创建一个新的列表条目，其中包含触发规则的主机的时间戳和源 IP 地址。该匹配将始终返回成功，除非前面有 ! 标志，这种情况下会返回失败。 This creates a new list entry in the named recent list, which contains a timestamp and the source IP address of the host that triggered the rule. This match will always return success, unless it is preceded by a ! sign, in which case it will return failure.
匹配	--r检查
核心	2.4、2.5 和 2.6
例子	iptables -A 输出 -m 最近 --name examplelist --rcheck
解释	--rcheck 选项将检查数据包的源 IP 地址是否在指定列表中。如果是，则匹配将返回 true，否则返回 false。可以使用 ! 来反转该选项。符号。在后一种情况下，如果源 IP 地址不在列表中，则返回 true，如果在列表中，则返回 false。 The --rcheck option will check if the source IP address of the packet is in the named list. If it is, the match will return true, otherwise it returns false. The option may be inverted by using the ! sign. In the later case, it will return true if the source IP address is not in the list, and false if it is in the list.
匹配	- 更新
核心	2.4、2.5 和 2.6
例子	iptables -A 输出 -m 最近 --name examplelist --update
解释	如果源组合在指定列表中可用，并且它还会更新列表中的最后查看时间，则此匹配为 true。通过设置 ! 也可以逆转这场比赛。在比赛前面做标记。例如， ！ - 更新。 This match is true if the source combination is available in the specified list and it also updates the last-seen time in the list. This match may also be reversed by setting the ! mark in front of the match. For example, ! --update.
匹配	- 消除
核心	2.4、2.5 和 2.6
例子	iptables -A INPUT -m 最近 --name example --remove
解释	此匹配将尝试在列表中查找数据包的源地址，如果数据包存在则返回 true。它还将从列表中删除相应的列表条目。该命令也可以与 ! 反转。符号。 This match will try to find the source address of the packet in the list, and returns true if the packet is there. It will also remove the corresponding list entry from the list. The command is also possible to inverse with the ! sign.
匹配	--秒
核心	2.4、2.5 和 2.6
例子	iptables -A INPUT -m 最近 --name example --check --seconds 60
解释	此匹配仅与 --check 和 --update 匹配一起有效。--seconds 匹配用于指定自最近列表中更新“上次看到”列以来的时间。如果最后看到的列早于此值（以秒为单位），则匹配返回 false。除此之外，最近的匹配工作正常，因此源地址必须仍然在列表中才能真正返回匹配。 This match is only valid together with the --check and --update matches. The --seconds match is used to specify how long since the "last seen" column was updated in the recent list. If the last seen column was older than this amount in seconds, the match returns false. Other than this the recent match works as normal, so the source address must still be in the list for a true return of the match.
匹配	--点击次数
核心	2.4、2.5 和 2.6
例子	iptables -A INPUT -m 最近 --name example --check --hitcount 20
解释	--hitcount 匹配必须与 --check 或 --update 匹配一起使用，它将限制匹配仅包含至少已看到 hitcount 数量的数据包的数据包。如果此匹配与 --seconds 匹配一起使用，则将要求在特定时间范围内看到指定的 hitcount 数据包。这场比赛也可以通过添加 ! 来逆转。在比赛前签名。与 --seconds 匹配一起，这意味着在指定的时间范围内可能已经看到了最大数量的数据包。如果两个匹配都相反，则在最后的最短秒数内可能已看到此数量的数据包的最大值。 The --hitcount match must be used together with the --check or --update matches and it will limit the match to only include packets that have seen at least the hitcount amount of packets. If this match is used together with the --seconds match, it will require the specified hitcount packets to be seen in the specific timeframe. This match may also be reversed by adding a ! sign in front of the match. Together with the --seconds match, this means that a maximum of this amount of packets may have been seen during the specified timeframe. If both of the matches are inversed, then a maximum of this amount of packets may have been seen during the last minumum of seconds.
匹配	--rttl
核心	2.4、2.5 和 2.6
例子	iptables -A INPUT -m 最近 --name 示例 --check --rttl
解释	--rttl 匹配用于验证当前数据包的 TTL 值是否与用于设置最近列表中原始条目的原始数据包相同。这可以用来验证人们没有通过利用最近的匹配来欺骗他们的源地址来拒绝其他人访问您的服务器。 The --rttl match is used to verify that the TTL value of the current packet is the same as the original packet that was used to set the original entry in the recent list. This can be used to verify that people are not spoofing their source address to deny others access to your servers by making use of the recent match.
匹配	--r源
核心	2.4、2.5 和 2.6
例子	iptables -A INPUT -m 最近 --name 示例 --rsource
解释	--rsource match 用于告诉最近的匹配将源地址和端口保存在最近的列表中。这是最近匹配的默认行为。 The --rsource match is used to tell the recent match to save the source address and port in the recent list. This is the default behavior of the recent match.
匹配	--rdest
核心	2.4、2.5 和 2.6
例子	iptables -A INPUT -m 最近 --name 示例 --rdest
解释	--rdest 匹配与 --rsource 匹配相反，它告诉最近的匹配将目标地址和端口保存到最近的列表中。 The --rdest match is the opposite of the --rsource match in that it tells the recent match to save the destination address and port to the recent list.

我创建了一个关于如何使用最近匹配的小示例脚本，您可以在Recent-match.txt部分中找到该脚本。

I have created a small sample script of how the recent match can be used, which you can find in the Recent-match.txt section.

简而言之，这是 netfilter 中状态引擎的一个糟糕的替代品。该版本在创建时考虑了 http 服务器，但适用于任何 TCP 连接。首先，我们创建了两个名为 http-recent 和 http-recent-final 的链。http-recent 链用于连接的起始阶段，用于实际的数据传输，而 http-recent-final 链用于最后的 FIN/ACK、FIN 握手。

Briefly, this is a poor replacement for the state engine available in netfilter. This version was created with a http server in mind, but will work with any TCP connection. First we have created two chains named http-recent and http-recent-final. The http-recent chain is used in the starting stages of the connection, and for the actual data transmission, while the http-recent-final chain is used for the last and final FIN/ACK, FIN handshake.

这是对内置状态引擎的非常糟糕的替代，并且无法处理状态引擎可以处理的所有可能性。然而，这是一个很好的例子，说明了可以在最近的比赛中做什么而不必太具体。不要在现实环境中使用此示例。它很慢，对特殊情况的处理很糟糕，并且通常只应该用作示例。 This is a very bad replacement for the built in state engine and can not handle all of the possibilities that the state engine can handle. However, it is a good example of what can be done with the recent match without being too specific. Do not use this example in a real world environment. It is slow, handles special cases badly, and should generally never be used more than as an example. 例如，它不处理连接上的关闭端口、异步 FIN 握手（连接方之一关闭，而另一方继续发送数据）等。 For example, it does not handle closed ports on connection, asyncronuous FIN handshake (where one of the connected parties closes down, while the other continues to send data), etc.

让我们通过示例规则集跟踪数据包。首先，数据包进入 INPUT 链，然后我们将其发送到 http-recent 链。

Let's follow a packet through the example ruleset. First a packet enters the INPUT chain, and we send it to the http-recent chain.

1. 第一个数据包应该是 SYN 数据包，并且不应设置 ACK、FIN 或 RST 位。因此它使用 --tcp-flags SYN,ACK,FIN,RST SYN 行进行匹配。此时，我们使用 -m recent --name httplist --set 行将连接添加到 httplist。最后我们接受了这个数据包。

2. The first packet should be a SYN packet, and should not have the ACK,FIN or RST bits set. Hence it is matched using the --tcp-flags SYN,ACK,FIN,RST SYN line. At this point we add the connection to the httplist using -m recent --name httplist --set line. Finally we accept the packet.

3. 在第一个数据包之后，我们应该收到一个 SYN/ACK 数据包以确认已收到 SYN 数据包。这可以使用 --tcp-flags SYN,ACK,FIN,RST SYN,ACK 行进行匹配。此时 FIN 和 RST 也应该是非法的。此时，我们使用 -m 最近 --name httplist --update 更新 httplist 中的条目，最后我们接受该数据包。

4. After the first packet we should receive a SYN/ACK packet to acknowledge that the SYN packet was received. This can be matched using the --tcp-flags SYN,ACK,FIN,RST SYN,ACK line. FIN and RST should be illegal at this point as well. At this point we update the entry in the httplist using -m recent --name httplist --update and finally we ACCEPT the packet.

5. 现在我们应该从连接的原始创建者处获得最终的 ACK 数据包，以确认服务器发送的 SYN/ACK。SYN、FIN 和 RST 在连接点上是非法的，因此该行应类似于 --tcp-flags SYN,ACK,FIN,RST ACK。我们以与上一步完全相同的方式更新列表，并接受它。

6. By now we should get a final ACK packet, from the original creater of the connection, to acknowledge the SYN/ACK sent by the server. SYN, FIN and RST are illegal at this point of the connection, so the line should look like --tcp-flags SYN,ACK,FIN,RST ACK. We update the list in exactly the same way as in the previous step, and ACCEPT it.

7. 此时就可以开始数据传输了。连接现在不应包含任何 SYN 数据包，但它将包含 ACK 数据包以确认发送的数据包。每次我们看到这样的数据包时，我们都会更新列表并接受这些数据包。

8. At this point the data transmission can start. The connection should never contain any SYN packet now, but it will contain ACK packets to acknowledge the data packets that are sent. Each time we see any packet like this, we update the list and ACCEPT the packets.

9. 传输可以通过两种方式结束，最简单的是RST数据包。RST 只会重置连接，然后连接就会终止。通过 FIN/ACK，另一个端点用 FIN 进行应答，这将关闭连接，以便 FIN/ACK 的原始源无法再发送任何数据。FIN 的接收者仍然能够发送数据，因此我们将连接发送到“最终”阶段链来处理其余部分。

10. The transmission can be ended in two ways, the simplest is the RST packet. RST will simply reset the connection and it will die. With FIN/ACK, the other endpoint answers with a FIN, and this closes down the connection so that the original source of the FIN/ACK can no longer send any data. The receiver of the FIN, will still be able to send data, hence we send the connection to a "final" stage chain to handle the rest.

11. 在 http-recent-final 链中，我们检查数据包是否仍在 httplist 中，如果是，则将其发送到 http-recent-final1 链。在该链中，我们从 httplist 中删除连接并将其添加到 http-recent-final 列表中。如果连接已被删除并移至 http-recent-final 列表，我们将数据包发送到 http-recent-final2 链。

12. In the http-recent-final chain we check if the packet is still in the httplist, and if so, we send it to the http-recent-final1 chain. In that chain we remove the connection from the httplist and add it to the http-recent-final list instead. If the connection has already been removed and moved over to the http-recent-final list, we send te packet to the http-recent-final2 chain.

13. 在最终的 http-recent-final2 链中，我们等待非关闭端完成发送数据，并从其端关闭连接。完成此操作后，连接将被完全删除。

14. In the final http-recent-final2 chain, we wait for the non-closed side to finish sending its data, and to close the connection from their side as well. Once this is done, the connection is completely removed.

正如您所看到的，最近的列表可能会变得相当复杂，但如果需要的话，它会给您提供大量的可能性。尽管如此，请记住不要重新发明轮子。如果您需要的功能已经实现，请尝试使用它，而不是尝试创建自己的解决方案。

As you can see the recent list can become quite complex, but it will give you a huge set of possibilities if need be. Still, try and remember not to reinvent the wheel. If the ability you need is already implemented, try and use it instead of trying to create your own solution.

下一步是什么？

What's next?

上一章介绍了 iptables 中可以使用的匹配项以及它们的功能。如您所见，iptables 和 netfilter 的匹配能力非常完善且非常灵活。下一章将详细讨论目标以及它们能够做什么。您将在该章中注意到 Linux 防火墙的功能。

The last chapter has been about the matches that can be used in iptables and what they are capable of doing. The matching capability of iptables and netfilter is extremely well developed and very flexible as you have seen. The next chapter will discuss the targets in detail and what they are able to do. You will notice in that chapter as well the capabilities of Linux firewalling.

接受目标

ACCEPT target

这个目标不需要更多的选择。一旦数据包的匹配规范完全满足，并且我们指定 ACCEPT 作为目标，规则就会被接受，并且不会继续遍历当前链或同一个表中的任何其他链。但请注意，在一个链中接受的数据包可能仍会穿过其他表中的链，并且仍可能被丢弃在那里。这个目标没有什么特别之处，它不需要也不可能向目标添加选项。要使用此目标，我们只需指定 -j ACCEPT。

This target needs no further options. As soon as the match specification for a packet has been fully satisfied, and we specify ACCEPT as the target, the rule is accepted and will not continue traversing the current chain or any other ones in the same table. Note however, that a packet that was accepted in one chain might still travel through chains within other tables, and could still be dropped there. There is nothing special about this target whatsoever, and it does not require, nor have the possibility of, adding options to the target. To use this target, we simply specify -j ACCEPT.

可在 Linux 内核 2.3、2.4、2.5 和 2.6 下运行。 Works under Linux kernel 2.3, 2.4, 2.5 and 2.6.

分类目标

CLASSIFY target

CLASSIFY 目标可用于对数据包进行分类，这种方式可由多个不同的 qdisc（队列规则）使用。例如，atm、cbq、dsmark、pfifo_fast、htb 和 prio qdisc。有关 qdisc 和流量控制的更多信息，请访问Linux 高级路由和流量控制操作方法网页。

The CLASSIFY target can be used to classify packets in such a way that can be used by a couple of different qdiscs (Queue Disciplines). For example, atm, cbq, dsmark, pfifo_fast, htb and the prio qdiscs. For more information about qdiscs and traffic controlling, visit the Linux Advanced Routing and Traffic Control HOW-TO webpage.

CLASSIFY 目标仅在 mangle 表的 POSTROUTING 链中有效。

The CLASSIFY target is only valid in the POSTROUTING chain of the mangle table.

在 Linux 内核 2.5 和 2.6 下运行。 Works under Linux kernel 2.5 and 2.6.

集群IP目标

CLUSTERIP target

CLUSTERIP 目标用于创建简单的节点集群，以循环方式响应相同的 IP 和 MAC 地址。这是一种简单的集群形式，您可以在参与集群的所有主机上设置虚拟 IP (VIP)，然后在应该响应请求的每台主机上使用 CLUSTERIP。CLUSTERIP 匹配不需要特殊的负载平衡硬件或机器，它只是在机器集群的每个主机部分上完成工作。它是一个非常简单的集群解决方案，不适合大型和复杂的集群，也没有内置的心跳处理，但它应该可以轻松地实现为一个简单的脚本。

The CLUSTERIP target is used to create simple clusters of nodes answering to the same IP and MAC address in a round robin fashion. This is a simple form of clustering where you set up a Virtual IP (VIP) on all hosts participating in the cluster, and then use the CLUSTERIP on each host that is supposed to answer the requests. The CLUSTERIP match requires no special load balancing hardware or machines, it simply does its work on each host part of the cluster of machines. It is a very simple clustering solution and not suited for large and complex clusters, neither does it have built in heartbeat handling, but it should be easily implemented as a simple script.

集群中的所有服务器都使用通用的多播 MAC 作为 VIP，然后在 CLUSTERIP 目标中使用特殊的哈希算法来确定集群参与者中的哪些人应该响应每个连接。组播 MAC 是以 01:00:5e 作为前 24 位开始的 MAC 地址。多播 MAC 的示例为 01:00:5e:00:00:20。VIP 可以是任何 IP 地址，但在所有主机上也必须相同。

All servers in the cluster uses a common Multicast MAC for a VIP, and then a special hash algorithm is used within the CLUSTERIP target to figure out who of the cluster participants should respond to each connection. A Multicast MAC is a MAC address starting with 01:00:5e as the first 24 bits. an example of a Multicast MAC would be 01:00:5e:00:00:20. The VIP can be any IP address, but must be the same on all hosts as well.

请记住，CLUSTERIP 可能会破坏 SSH 等协议。连接将正确进行，但如果您在同一时间再次尝试连接到同一台主机，您可能会使用不同的密钥集连接到集群中的另一台计算机，因此您的 ssh 客户端可能会拒绝连接或给出错误。因此，这对于某些协议来说不能很好地工作，并且添加可用于维护和管理的单独地址可能是一个好主意。另一种解决方案是在参与集群的所有主机上使用相同的 SSH 密钥。 Remember that the CLUSTERIP might break protocols such as SSH et cetera. The connection will go through properly, but if you try the same time again to the same host, you might be connected to another machine in the cluster, with a different keyset, and hence your ssh client might refuse to connect or give you errors. For this reason, this will not work very well with some protocols, and it might be a good idea to add separate addresses that can be used for maintenance and administration. Another solution is to use the same SSH keys on all hosts participating in the cluster.

集群可以通过三种hash模式进行负载均衡。第一个只有源 IP (sourceip)，第二个是源 IP 和源端口 (sourceip-sourceport)，第三个是源 IP、源端口和目标端口 (sourceip-sourceport-destport)。第一个可能是一个好主意，您需要记住连接之间的状态，例如带有购物车的网络服务器可以保存连接之间的状态，这种负载平衡可能会变得有点不均匀——不同的机器可能会获得更高的负载比其他的等等——因为来自同一源 IP 的连接将转到同一服务器。当您希望负载平衡更加均匀，并且不必在每个服务器上的连接之间保留状态时，sourceip-sourceport 哈希可能是一个好主意。例如，一个带有简单搜索引擎的大型信息网页可能是一个好主意。第三个也是最后一个哈希模式，sourceip-sourceport-destport，可能是一个好主意，如果您的主机正在运行多个服务，并且不需要在连接之间保留任何状态。例如，这可能是同一主机上的简单 ntp、dns 和 www 服务器。因此，到每个新目的地的每个连接都将被“重新协商”——实际上没有进行任何协商，它基本上只是一个循环系统，每个主机都会收到一个连接。例如，这可能是同一主机上的简单 ntp、dns 和 www 服务器。因此，到每个新目的地的每个连接都将被“重新协商”——实际上没有进行任何协商，它基本上只是一个循环系统，每个主机都会收到一个连接。例如，这可能是同一主机上的简单 ntp、dns 和 www 服务器。因此，到每个新目的地的每个连接都将被“重新协商”——实际上没有进行任何协商，它基本上只是一个循环系统，每个主机都会收到一个连接。

The cluster can be loadbalanced with three kinds of hashmodes. The first one is only source IP (sourceip), the second is source IP and source port (sourceip-sourceport) and the third one is source IP, source port and destination port (sourceip-sourceport-destport). The first one might be a good idea where you need to remember states between connections, for example a webserver with a shopping cart that keeps state between connections, this load-balancing might become a little bit uneven -- different machines might get a higher loads than others, et cetera -- since connections from the same source IP will go to the same server. The sourceip-sourceport hash might be a good idea where you want to get the load-balancing a little bit more even, and where state does not have to be kept between connections on each server. For example, a large informational webpage with perhaps a simple search engine might be a good idea here. The third and last hashmode, sourceip-sourceport-destport, might be a good idea where you have a host with several services running that does not require any state to be preserved between connections. This might for example be a simple ntp, dns and www server on the same host. Each connection to each new destination would hence be "renegotiated" -- actually no negotiation goes on, it is basically just a round robin system and each host receives one connection each.

每个 CLUSTERIP 集群 根据集群的 VIP在/proc/net/ipt_CLUSTERIP目录中获取一个单独的文件。例如，如果 VIP 是 192.168.0.5，您可以 cat /proc/net/ipt_CLUSTERIP/192.168.0.5 来查看该计算机正在响应哪些节点。要使机器应答另一台机器（假设为节点 2），请使用 echo "+2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5 添加它。要删除它，请运行 echo "-2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5。

Each CLUSTERIP cluster gets a separate file in the /proc/net/ipt_CLUSTERIP directory, based on the VIP of the cluster. If the VIP is 192.168.0.5 for example, you could cat /proc/net/ipt_CLUSTERIP/192.168.0.5 to see which nodes this machine is answering for. To make the machine answer for another machine, lets say node 2, add it using echo "+2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5. To remove it, run echo "-2" >> /proc/net/ipt_CLUSTERIP/192.168.0.5.